Wiki/Report of Meeting 2024-04-18

From J Wiki
Jump to navigation Jump to search

Report of Meeting 2024-04-18

Present: Ed Gottsman, Raul Miller, and Bob Therriault

Full transcripts of this meeting are now available below on this wiki page.

1) A quick discussion about Jan Jacobs mapping of the wiki to SVG. Jan has been very generous in allowing us to use his work as a way to evaluate the categories of the wiki. This is a commercial application that he has developed, but he is interested in how the J Wiki might be used to further develop his application. Ed has looked at dendrograms http://www.sthda.com/english/wiki/beautiful-dendrogram-visualizations-in-r-5-must-known-methods-unsupervised-machine-learning and feels that a circular dendrogram would be a good space effective way to represent the information. Ed is hoping to have something that he can show at the next meeting. Bob clarified that this experiment is not attached to Jan's categorization scheme. Ed feels that the structure of the category trees has never really been shown and it may be interesting to include the number of pages in each category.

2) Bob talked about his work in the week with the template and trying to adapt the generated category tree to the grid display. The generated tree does not give a lot of options for reformulation. Instead the information of the category tree would be generated manually once for the template and then imported to the bottom of the page. A category page would have the page titles in the upper area, while the content pages would have their content in the upper area.

3) Raul posted a link into the chat to overcome the challenges of using Javascript in the development of the the wiki https://code.jsoftware.com/wiki/MediaWiki:Common.js. Raul also pointed out that on the wiki server J can be run against the database and that may be a path for future development. The actual interface for MediaWiki is in PHP. Raul also supplied a link to the layout of the database in Mediawiki https://www.mediawiki.org/wiki/Manual:Database_layout

4) Discussion of a stand-alone J Viewer. Raul reported a bug that he had seen in starting up a second J instance from JQt. The second instance should be independent, but it seems to be dependent on the first instance. Raul has reported this to Bill Lam and we will wait to see if Bill can clear up the bug and allow Ed to continue on with his development of the stand-alone J Wiki Viewer.

5) Bob talked about trying to incorporate the category trees into the template. Bob was considering using SVG in the templates to allow for a more interactive and responsive category tree. (Editor note: MediaWiki will allow SVG, but converts it to non-interactive png files, so this may not be useful for the wiki, but could still be useful for the J viewer.) Ed pointed out that hover based expansion can be very tricky because as the expansion moves things you end up hovering over a new area and creating unpredictably results. Bob wondered whether there was a way to do a fish-eye approach which allows you to remain centred over the area of interest. Ed feels that you would still see some of the same challenges and Bob may explore this. There was a quick discussion of tree-maps versus dendrograms. Bob wondered about ways to accommodate mobile devices and Ed warned against different experiences for different platforms.

6) Category discussion moved into the cloud categories that are not associated with the trees, but float free in the cloud. Ed thought that it is possible that Jan's work may provide a map of those disconnected categories. Bob felt that the quantitative information would enrich the qualitative approach that he had taken with his taxonomy. Bob felt that one of the things that is promising is that you can build trees that organize existing documentation. Ed pointed out that the J wiki has enough information and organizing it is the challenge.

For access to previous meeting reports https://code.jsoftware.com/wiki/Wiki_Development If you would like to participate in the development of the J wiki please contact us on the J forum and we will get you an invitation to the next J wiki meeting held on Thursdays at 23:00 (UTC) Next meeting is April 25, 2024.

Transcript

- Tactical error of updating Zoom

like five minutes before the meeting.

And they've made a lot of changes.

- Got a lot of changes.

- Yeah.

- There's an XKCD cartoon in which a character complains

that they just updated his software

and all these things that used to be easier

now difficult for no apparent reason.

He hates it.

And another character remarks

that he is not going to like getting old.

- Yeah, that's right.

Who moved my cheese?

- Yeah, exactly.

- For me right now, the timing is the issue.

I haven't had a chance to see what the new stuff can do.

So everything's just an inconvenience, but.

- Right, right.

And you've got to function currently in a meeting.

So it's very inconvenient.

- Yeah, that's my own fault.

I have nobody else to blame.

I should have wised up.

- Okay.

So I haven't heard back from Jan about the mapping stuff.

- Nope, not a word.

I did read the paper that he passed on.

I would have to say,

I'm curious about the idea of laying out

a hierarchy as geography.

Let me share my screen.

So I'm looking at these dendrograms

and they strike me as a more area efficient way

of laying out a tree.

I haven't actually, let's see if this is bigger.

Yeah.

And I can't help but wonder if the,

I forget what the count is,

but it's under 200 nodes in your hierarchy.

That is excluding what we call the tags.

Couldn't be laid out in a dendrogram

in the area that's available

in the left pane of the JViewer.

And so I've started to fool around with that.

It's a tricky, I think it's a tricky problem

if you try to do it right.

I'll be curious about whether

if you sort of take shortcuts,

you can still make it work with our particular hierarchy.

What I probably would not try to do

is the names of the nodes,

the names of the categories.

Instead, we're here, there are names.

I'd probably just have a number,

which would be the number of pages in that category node.

- With a tool tip for the name or something?

- Yeah, tool tip or a caption underneath,

something like that.

And then clicking on a category,

I've got a menu currently that I use

over on the browser side for,

it's that weak navigation mechanism

based on keywords that I've made,

which I will cheerfully pitch

in favor of almost anything else.

And what I'm thinking is when you click on a category,

that menu will fill in with the pages,

the names of the pages in that category.

- I can see doing the Dendrogram like with an SVG,

'cause that gives you the ability

to put layout text however you want,

but I don't know how you would tie,

you'd have to use JavaScript or something

to tie it into something updating elsewhere on the page.

Would you?

- I don't know about JavaScript.

Let's see.

So my restriction as I'm currently imagining this thing

is that it lives on an is a graph control

on the left side.

- Oh, you're not talking about the wiki,

you're talking about your, gotcha.

- But in principle, there's no reason why you couldn't do it

in the wiki as well, possibly using an SVG.

I think that's a perfectly reasonable thing to do.

You're absolutely right.

But this is a more area efficient layout

than a conventional top to bottom tree

or a left to right outline.

So I think it's got some potential in that regard

and I'm gonna experiment with it over the next week or so

and I hope to have something to show by Thursday next.

- And the circular is better than the traditional tree.

- Well, the problem with circular,

trying to get back to the meeting so I can,

oh, stop share, here we go, yeah.

The problem with the circular, it is more area efficient

so you can pack more nodes in

and it tends to be more forgiving as your tree gets deeper.

'Cause if you think about it,

your perimeter is getting wider

as your depth increases anyway, which is kind of convenient.

The problem with it is that perceptually

we're a little better able to handle

the conventional root and branch top to bottom layout

and certain things are a little more obvious about it

but we'll just have to try it and see.

It may be that it'll work out,

the dendrogram will work out just fine.

- And for Jan's stuff, I mean,

I was under the misapprehension

that he was actually using my categories, which he's not.

He's developing his own

based on the word count and everything.

So when you say the dendrogram would be my categories,

we're not really gonna be using Jan's process then?

- No, I have, this is, there are,

let a thousand flowers bloom, Bob, as the saying goes.

- Yeah, yeah.

- Yeah, no, I think it's entirely possible

that Jan will come up with a categorization scheme

that at least parts of which we might find very attractive.

In which case I'd be happy to use it.

In fact, my feeling is I'll use whatever you use,

whatever that turns out to be.

So that's what I'm experimenting with.

- And I'm in exactly the same position.

I'm willing to ditch mine.

Well, honestly, 'cause mine was just like,

throw spaghetti at the wall and see what sticks.

I mean, it was--

- I'm actually kind of interested

in what yours looks like in dendrogram form

in the sense that it's never actually been visible

as a single display to my knowledge.

- No, not really.

I mean, my cut and paste is kind of that,

but it's not really, doesn't really show the display.

So what I've done there is I've just created a page

that I could cut and paste the categories off

to make it easy to set them.

- And in addition to structure,

the other thing that I think has never been shown

in a single page is the page count for each node.

- Yeah.

- That's never been represented.

And I think that might be quite interesting.

- Yeah.

It's an option when you do the category trees.

- Sure, but even the category trees,

they go linearly down the margin

and they take several pages.

Something where you can just sort of look at the whole thing

is I think new and hence perhaps interesting.

- Yeah, no, I agree with you there.

The category pages, that's one of the challenges

that I'm facing working with them

is that they're long strips really.

- Yeah.

- And I'd like that to be a more shortened squat approach

to it.

- Yeah, well, shortened squat is what Dendrograms

are good at as far as I can tell.

So that might be something worth thinking about.

And to Roel's point, I mean, you are the SVG maven

of the group.

So you could consider trying to generate an SVG.

- Yeah.

- Dendrogram.

- Yeah, and I'm actually sort of,

when I was playing around with the different things

with template, what I realized is I've really got to go back

and recreate my categories.

I'm not gonna rely on the category tree built in stuff

to be able to show the category tree.

'Cause it's so structured as an HTML when it comes out,

you really can't work with it.

It's already built for you.

And there's not a lot of leeway in that.

But I still have a list of all the categories.

And I still have the option to turn off

the subcategories at the top,

'cause I've done that before.

Put the pages, and then I can build my own tree

and put that as a template and drop it wherever I want.

And I can control the space on that.

- So manually build your own tree.

- I can manually build my own tree once as a template,

and then just pop that template in.

And right now my feeling is,

is that I would put that template at the bottom of the page

for two reasons.

One is it would allow me to put that template in

on every content page and not get in the way of the content.

It's always gonna be there at the bottom of the page

if you want it.

Or the category pages themselves,

that content will become those sub pages.

Sorry, the pages that are attached to them,

not the subcategories.

- The titles of the pages that are attached to them.

- Exactly, and then underneath that,

you would see the grid layout of those categories.

- And are you still thinking in terms of showing

actual individual, actual pages content in that framework?

- Well, in a way, because like not showing the pages

at the same time, I would show all the pages

in under that category.

- Distinguish for me between page titles and page content.

- Okay, page content would be the page.

You click on a page title, link to a page title,

you see the page content, you're on that page.

- And only the page content.

- And only the page content.

Although at the bottom of that,

that's where I would put the category tree layout.

So you'd have a way back quickly,

but you wouldn't see all the other pages

in a given category while you're looking at a page.

- All the other page titles in a given category.

- All the other page titles in a given category.

You wouldn't see those.

If you went to a specific category page,

you would see all the other page titles with that.

So when you go to the category page,

the content is the page titles

associated with that category.

And underneath is your category tree.

And in a typical content page,

the content is what you see

and then underneath is the category tree.

- Right.

- So it would be a two-step process

to get back to seeing other pages

that might be in that same category.

'Cause you have to go down to the category tree,

select the category you're in,

and then it would take you back up

to the actual category page,

which now has the page content of the other pages

you might be interested in.

- Okay.

Well, I mean, once you've got the

sort of underlying mechanisms together,

and we'll look at that link.

Thank you.

I assume you're making-

- There's actually another thing.

That link is for a different topic.

It's actually- - Oh, okay.

- I am thinking about end game and maintainability stuff.

But my thought is once he has a handcrafted

tree representation up and implemented in J,

the J wiki has the ability to run J

against database queries and against even web queries.

It has a J interpreter on it.

And so hypothetically speaking,

it could be like a cron job or something up there

on the machine that's rebuilding that category tree

from the categories that are in the system.

So that's categories, it would,

you'd still need to keep an eye on it.

So because there's layout issues that you're gonna handle,

they need judgment calls on,

but at least it would be adaptive.

And for minor changes, it would,

and a glaring issue would eventually show up too,

because you'd see it.

But that's, so for this particular purpose,

I'm thinking that once he has a working example

that he feels comfortable with

and he thinks it's good to go ahead on,

we could actually deploy it into the J wiki

as a semi-automated system.

But I also posted that link in the chat

because of the concept of tying it into,

tying things together that we haven't been able to tie,

you know, we've been going to extreme lengths on

because we couldn't do JavaScript.

There's actually a way around that.

- Because we couldn't do JavaScript?

- Right, there's been some things

that we've been reluctant to do

because the wiki didn't support it.

And, you know, it's just minor, minor things

that we'd have to do jobs, we can't do that.

And that's really not an obstacle.

It's just a, I mean, it is an obstacle,

it's an efficiency obstacle,

but it's not a roadblock necessarily,

as long as we can stay in the right area.

- You said the wiki can actually run J, is that right?

- No, yes, the wiki, on the server,

J, you can run J console,

and J console can talk to the database

that manages the wiki.

And they can, you know, it can,

there's an API there that you'd have to,

and you'd probably want a local copy

so that you could really, or a test machine,

maybe the Crisco setup.

That's the old test wiki.

One of the things that we were doing there

is that it did have J.

So once we have a good idea of what we want J to do,

which you really have to develop outside the wiki,

you know, then you could go to a test wiki

and finish it up and tie it in and debug it there.

And then once we're happy with that,

it can be deployed to the real wiki.

So that's a way forward for things that we decide

are worthwhile after investigating them

and require the power of J to,

you know, we don't want it to run on every page

every time that somebody loads a page

'cause it's way too much computation,

but we still want the automation there.

That's fine.

- That's definitely viable.

- It's just an SQL database.

It's, you know, structures representing the pages

and links and categories and people.

- Oh, I'm sorry.

I didn't know there was a SQL database behind the J wiki.

Could you peel back one layer of detail on that for me?

- What layer are you interested in?

- I would like to understand the relationship

between the SQL database

and the media wiki manifestation that we interact with.

- That's, name starts with a P,

I sound like my tongue.

- PHP.

- PHP, yeah.

That's a PHP layer.

- Okay.

- It's a overly ornate, heavily abstracted

object framework in PHP.

So it's really annoying to work with

because it's all poorly documented abstractions.

Where, you know, you're expected to know the pattern

and then the people who did the pattern

have long since gone away

and people that maintain the pattern

have hacked at it a little bit

and gone another direction and re-implemented stuff.

Typical enterprise.

- So what about the underlying database?

Have you looked at it?

- Oh, yeah, a little bit.

It's got a page table.

It's got a page title relationship there, I think.

It's got a category table, I think.

- It must have history in some sense.

- Yeah, you can just probably do MediaWiki SQL or something.

- Oh, right, of course it would be standard.

Yeah, okay, okay.

Thank you, yes.

That's all I needed, I appreciate it.

- Or actually MediaWiki schema

might be better for what we're doing right now.

- I have become a chat GPT user.

I will ask chat GPT about it and see what it says.

It does occasionally hallucinate.

You have to check or feel competent enough

in your ability to be a critic,

but it can be quite useful.

- I'm also a Zoom user, so I'll throw the link in the chat.

I think it's irrelevant.

- And if it hallucinates, it can be a source of entertainment.

- Essential hallucination.

- Yeah, yeah, yeah.

- Oh, thank you.

- I think the next thing that I sort of tossed in

is whether you had made any progress

on the standalone JViewer,

'cause I think there were some things that happened.

- Oh, right, yeah, yeah, yeah, yeah, yeah, yeah.

Right, I'm a little stuck on that.

Actually, I wanted to ask both of you, I suppose.

- I've got a bug report on an issue related to that.

- Oh, okay.

- I'm not sure if it's related to the JViewer.

- I'm not sure if it's related to the JViewer.

- I've got an issue related to that that I posted

where JQT is firing up a second JQ instance.

Well, in some cases, even though it's supposed

to spawn an independent JQ instance

that runs independently, it's not doing that

and it's waiting for the independent instance to complete.

- That's what I wanted to ask about.

I was using-- - Yeah, that's a bug.

I reported it.

It's probably gonna need nudging up in a few weeks

because Bill doesn't seem to notice it,

and he's the one that's our current maestro

of all the inordinate complexity of the JQT threading hacks.

- Okay.

- I'm kind of on the hook there,

but it's a very, very, very distant hook.

I'd have to rewrite JQT to solve it.

- But also, Ro, you're retired.

I mean, hell.

- Yeah, why not? (laughs)

- I suppose, yeah.

Fair point, right?

Touche.

Yeah, I was finding, and that's what I wanted to ask about,

that I forget what syntax I was using.

I was using start and shell, I think.

- Yeah, shell is the right J stub,

but there's something that JQT is doing

which interacts with the underlying OS

that I don't currently understand it,

and anyways, such is life.

So I-- - That's a little better.

So I can safely defer that for a few weeks

and sort of hope that it gets fixed by itself.

I love that kind of problem.

I just love it.

- Finger pointing.

Here's a hard thing for you.

(both laughing)

Please, delegation.

- Well, I like Bill, so I mean, you know.

If he knows it's an issue that's worth looking at,

I'm sure he will, but that might be the question,

is whether or not it moves up his list.

- Yeah.

So, and I haven't looked at Mac OS or Linux.

I was having a problem with Mac OS where,

I have looked at Mac OS.

The problem there was that you could,

I was unable to pass parameters into JQT.

I could start JQT,

but I couldn't successfully pass anything into it.

No ARGs, no nothing.

So I need to dig into that a little more.

So yeah, that's sort of,

that's on the back burner at this point.

As something that is frustrating and hence not attractive,

but it has not been abandoned.

It is not a cold stove at the moment.

- Which I guess brings it over to my work

with the grid and the templates.

And I sort of touched on that.

One of the things I found out was that

the built-in category viewers are pretty much producing

their own HTML to show,

which is completely reasonable

because it's a Wiki based on HTML,

but it means that you can't go in

and you can turn things on and off.

Like I can turn off subcategories and stuff,

but once they're in there,

they're all inline display stuff.

So I can't overwrite it with CSS.

So it takes me out of the loop there.

And that's when I realized it made more sense

just to use, I already have the categories

and then I just need to figure out

how to display them within a grid.

And I'm working on that.

One of the things for my way of getting it,

the information more dense,

I was going to try and do something with SVG,

where when you actually hover over,

it will actually slide the rest of the category open.

And then when you go, as you go along,

it'll just keep shifting along with you,

which is great if you can hover,

but then if you were on an iPad or a phone

or stuff like that,

what my solution was going to be

and the first thing I was going to work on

is just generating a page where you can go to

so that it's got all the categories,

it's all laid out for you.

So at least you can see it,

you know what you're looking for,

but for the computer example,

where you're not using touch,

the hover, I think it would be a really powerful way

to quickly go through the categories.

Hover-based expansion is tricky.

The viewer uses it in a couple of cases,

but you run into a problem where you hover on something

and its children expand to fill the area.

And then you move across the children

and then you jump to the, yeah, yeah.

Right.

Because the ground is shifting under your feet

and because you don't have any absolute reference points,

which the viewer does when it does this,

it has absolute reference points.

If you don't have those,

if you're sliding everything around,

and I say that not quite being able to visualize

what you have in mind,

what you're trying to do,

or you have in mind may in fact not be a problem.

But I mentioned it as something you can run into.

Oh, okay.

All right.

It was something I hadn't taken into account,

but you're right.

In your head, it seems great.

But every time I've done it,

I'll be like, oh yeah, shoot, that's right.

I forgot it does that.

Okay.

I read something, was it two days ago,

about it was the first navigation system in automobiles.

And like the very, it was in the 1980s.

They had a CRT you could put in a car

and they had a box sitting in the back

and it actually could send you around streets

and do locations.

This was before GPS was available.

So they had to do dead reckoning.

There was an awful lot to it.

- Wow, yeah.

- Yeah, no, it's really,

was it TICO or something like that it was called?

I can't remember for sure.

But anyway, it was a really good article

about all the stuff that had gone through

and what they needed to do.

But right at the end of it,

they talked about the name

and the name was based on Polynesian navigators.

And the concept for a Polynesian navigator

is not that you're moving through islands.

The islands are moving past you.

And when you said that about the,

I'm just, and I'm just without doing research

or thinking further about it,

I'm wondering whether if the map moves

and the mouse stays in the center,

is that something like, can you coach it over?

And essentially you see the same sort of thing

when you're zooming in on part of a screen

and the zoom follows the mouse, right?

So it moves around.

But what I'm wondering is, is it possible,

and I don't know the answer to this,

but whether it's possible to keep the thing centered

and have the map move around underneath you?

Because that would mean that you were always

over the central spot and it expands away from you.

- That would work for full screen,

but you need to have a way of disengaging at some point.

So it's probably gonna be a click and drag interface

rather than a, always, than a complete Hoover interface.

- Well, actually, I mean, what you're describing, Bob,

I think is a fisheye style of interface.

Where the focus, the lens focus is the mouse.

So, which is not quite what you described,

but it could be.

It wouldn't be the cursor

that would be in the center of the screen.

The cursor might be invisible.

It doesn't really matter.

But there would be a center point.

- Yeah.

- And yeah, the map would be moving

under a fisheye basically.

And that's fine.

That works great if you can do the math.

- Yeah.

- The problem comes not so much

when the islands are moving, but you're stationary,

as when the islands are moving with respect to each other.

That's when things get dicey.

And that's what category expansion in place

and sliding category labels and contents around does to you.

That's islands moving with respect to each other.

- Yeah.

So, I guess what I was thinking was,

is you probably would be expanding

whatever was under your fisheye.

And you would probably be expanding one layer out from that.

And one layer up from that.

So that as you're moving around, when you move up a layer,

the layer two below shrinks again.

- Yeah.

The effect that you get there is that very small movements

of your mouse can result in significant changes

in the display.

- Yeah.

- And as a result, when you try to hit a target,

you're moving down towards the target

and the target's moving up towards you.

And we tried that at one point with the viewer.

We had this thing where it was one of the notions

that Ruhl was interested in when I had implemented it.

And that business of having two motions at once,

one directly under your control

and one the indirect result of your movement is dicey.

- Yeah. - Put it that way.

- I'll give it some thought.

I don't know.

- Give it some thought because actually,

Ruhl has a good point,

which is that you may get to the point,

there may be two modes.

There's one where you're moving the fisheye around

and there's one where the fisheye movement is frozen

and you're moving the mouse around and hitting targets

that have been brought into focus by the fisheye.

- Yeah, yeah.

- So that's very reasonable or vice versa.

So shift, the shift key turns on the fisheye

focus navigation and you release the shift key

and it's just a standard issue,

clicking on a map to see interesting points of interest.

- Yeah.

Well, failing that,

what I would probably do is just go to some kind of a format

where I could show the,

using the grid,

I would probably split up the different categories

in a way that was wider and less deep,

which would be particularly important to try and like,

try not to go more than what a page view would be

so that you're not having to go up and down your page

to see it.

- You could do worse if you're interested in that

than to look into tree maps.

- Hmm.

- I don't wanna use them for the dendrogram style interface

because...

- Well, and then that's another thing

that I hadn't thought about,

but a dendrogram would be another way to do it, right?

- Yeah, absolutely.

- Yeah.

- The problem with tree maps is I've never liked tree maps.

I don't find them intuitive.

I find it hard to follow the hierarchy.

I don't quite get it.

Actually, I heard a job talk from the grad student

who implemented Ben Schneiderman's idea,

Ben Schneiderman at the University of Maryland.

He was a user experience guy back in the day.

And Schneiderman's take,

the reason, sort of the philosophical insight that he had

that led him to tree maps was a pixel

is a terrible thing to waste.

And all the tree layout mechanisms that we've got,

including dendrograms, wind up wasting pixels on space

that can't be used for data.

And that is true of tree maps.

They are extraordinarily efficient users of space

when it comes to hierarchical layout.

But I would argue that they're even worse than dendrograms

in terms of the intuitive conveyance

of the hierarchy.

I don't, I'm not a fan,

but that doesn't mean they wouldn't be a good idea

in this case.

That might be something that you might be interested

in doing.

It would be a simpler problem.

- Yeah.

- There's actually, there are,

I'm pretty sure there are J libraries

or AJ library that will do tree maps.

And I would imagine there are also

JavaScript implementations.

And there are a number of algorithms out there.

It's a pretty well trodden area.

- Well, when you get to the,

and I'm not sure I would use this,

but it was in the J libraries,

the tree form of a verb,

they're essentially creating a tree map of the verb, right?

- Yeah.

- And they're using, I think it's Thorn to do it

and building it that way.

But it is a bit of a self problem in that sense.

- Oh, tree maps are absolutely a self problem.

I was just thinking how easy it is,

how easy is it for you to get a hold of a solution

and exploit it?

- Yeah.

- And I think it might not be too bad.

- Yeah.

But that's kind of what I've been looking at

is moving that tree map to the bottom

and having consistent.

And content above, or if it's a category page,

the page is linked to that category page above

and leave the navigation that way.

- Yeah.

All right.

- And then there's work to do to build in

what we were talking about before with tool tips

and things like that,

where we can provide further information

when you're on a category to give a sense

of what you'd be looking at.

And that on the, for the mobile user,

there'd be a page that would include all that information.

So they'd be able to access it that way.

But it'll be one step removed for the mobile user.

- I see.

- Well, they won't be able to use hover, right?

- No.

- Tool tips won't work.

- No.

That's interesting.

- I could put a button beside each one.

Like, you know, make it some kind of a button

that you hit and it actually does a little.

- Yeah, I think that if you start to try to come up

with different user experiences by platform,

I think you're asking for it.

- Yeah.

- I think you're probably right.

Especially if somebody was used to using it

on their computer and then they flip over to their phone

and suddenly.

- For example.

- I mean, you know, it's the updating Zoom problem,

isn't it?

- It is.

It absolutely is.

(laughing)

It's even worse 'cause you can get a,

you can get a keyboard.

I used to have a keyboard and track pad for my iPad.

So I could hover on my iPad,

but I wouldn't have been able to

because your environment detection variable

would have said, nah, that guy doesn't have a pointer.

- Yeah, they are.

- I think it would have said that.

- Yeah, no, I think you're right.

I think it would.

I've heard that criticism before from people

who do have that set up is that,

why do I have to go to,

and you actually, I think you can get around it

by going in and resetting modes from your device,

but you're asking a lot of the user

to basically try and trick you back

into giving the performance that's already there.

- Right, and who knows what you will break by doing that,

but other things.

- Yeah. - Yeah, it's true.

Also, whatever layout display you land on,

Raul is still right.

You could do some sort of,

and I'd be happy to work on this,

do some sort of weekly generation exercise

that would produce the template or the HTML

or whatever it is that you need,

or the SVG for that matter,

that would reflect the current state

of the category hierarchy.

- The eyes, like,

it's not that the category hierarchy cannot change.

It absolutely can,

but it's the sort of thing that would probably be done once,

or maybe if a whole new area opened up,

maybe that would make a change to it,

but I don't see it being changed on a weekly basis.

- Okay, so it would be an exception kind of a thing.

- Where I do see it being useful

is when we were talking about the cloud categories

that aren't attached to that hierarchy.

- Yeah. - That would be cool.

- Those scare the hell out of me.

I mean, there's just no structure.

It's just several hundred categories

with one to maybe six at most pages associated with them.

I think that's where I'm counting on, Jan.

If Jan can come up with a category hierarchy,

it will include all of those pages

that are associated with those categories.

And maybe Jan will have a sort of unified field theory

of jwiki categorization that will encompass

both your categories and the tag categories.

- It may be as simple as looking at

what his categories have generated

and then going into those pages

and assigning them categories to the category tree.

- Possibly, yeah.

- You know, if there's areas of the category tree

that aren't dense enough,

and he's identified whole areas that would apply,

then those pages can get pulled over to those areas.

- Yeah, maybe.

I mean, we'll just have to see what he delivers,

but it's entirely possible that his contribution

will be one of editing rather than wholesale revamping.

- Yeah, possibly.

From reading some of the literature, though,

it's a great tool to have.

It's a tool that I wish I'd had in my back pocket

when I started doing the,

'cause it just grounds everything in the quantitative

that I'm completely functioning qualitatively, right?

Oh, this looks like a, this looks,

and I know that people do this and.

- Yeah, but Bob, you know, I mean,

to be able to say, well, it's quantitative

is not much of a defense when people say,

this is not helping me.

- Yeah.

- So I wouldn't denigrate your own efforts in that regard,

I guess is what I'm saying.

- No, I'm not.

But, and one of the things I discovered in that process,

and it remains to be made use of,

but the category trees are a great way

of structuring knowledge on a topic.

And there's nothing keeping you from creating a category

with subtrees that would walk somebody through a whole area

using existing pages.

You can categorize yourself on a topic,

and you could put that category tree

into the larger category tree,

and now if you're really interested in,

I don't know, statistics,

you could have somebody may have already gone in,

really familiar with statistics,

knows a whole bunch about the way the information

on the jWiki is set up,

and they just go in and pull all that information together,

and they just link it to the statistics in the hierarchy,

and bang, you've got a built-in great resource

that somebody is, with knowledge has curated.

- Joe's statistics.

- Joe's statistics, yeah.

Well, and it would probably be,

well, one of the guys I can think that might do it

would be Bill, is it Bill Such from Australia?

- Yeah, Bill.

- Yeah, yeah, 'cause I know he's,

I mean, he's written stuff on statistics,

and so he would be a person who could go in

and actually look at what's there and say,

yeah, that, yeah, yeah, yeah,

I know this is really important,

and we should have more of this,

but you can build the trees that way,

which is really neat.

- Yeah, yeah.

I do like the idea of not generating any more documentation.

I really feel like Jay has enough documentation,

but maybe organization is a good place to push.

That's entirely possible.

- Well, and talking not directly to the guys

who are doing the APL Wiki,

but working around them,

well, recently, I don't know whether you'd heard

Joey Tuttle passed away back in February.

- I did not, no.

- Yeah.

But he goes back a long way back to Iverson and everything,

and did a lot of really neat stuff in the early days.

And the benchmark, the JKT benchmark

for all the new versions of Jay that come out,

is what it was, a 50 by 50 random matrix

that was inverted.

And he's got the stats all the way back to the, you know,

Apple II, right?

(laughing)

And so, you know, I think it was like,

I can't remember if it was always 50 by 50,

but it was like, it went from minutes to seconds

to hundreds of seconds.

- Right, and it may not be the right metric anymore,

but it's like the Dow Jones Industrial Average,

it goes back forever, so we use it still.

- And he was the one that came up with that.

Anyway, I'd found out about that,

and then Marshall, 'cause I'd said I'd met Joey

at the 2014 conference in Toronto.

Just hadn't been passing,

but he seemed like a super neat guy,

really nice, really friendly, really open,

and just like, you know, a guy you'd wanna be around.

- Yeah.

(laughing)

- And then I was sad to hear he passed away,

and so I said that I'd met him there,

and Marshall said, "Yeah, same for me.

"I met him and I thought he was a really neat guy."

That reminds me, I should go and update the APL Wiki.

So he zipped off the APL,

and he used the obituary information

and built a whole, you know, topic about him.

And probably what I'll probably do

is go back in and link back to that,

'cause I'm probably not gonna do this,

trying to do the same thing,

but maybe under his member page,

I'll link back to it for people who want more information.

But the thing is that there's several,

I think there's probably a half dozen people

that are working on the APL Wiki,

continually generating pages that are of,

because it's the APL Wiki,

it's more of a general repository for APL information.

So it's got some J stuff, it's got K and Q,

it's got all of them,

and these guys are always updating it.

And I don't see the J Wiki has gone that direction at all.

It's gone more into the specialist.

I'm interested in this area, and I'm building it out.

So you get a lot of little math things.

There's not as much wider cultural aspects of it.

- Is, and I, maybe this is a question more for O.

Is APL more considered a general purpose

programming language by the APL community,

or is there still-

- APL has deeper roots, I think.

It's been around longer.

It's been a Wall Street tool for many decades.

It just has a bigger community.

So J started up as kind of an educational focus

and never really gotten up momentum

beyond a few community colleges.

Python kind of took over.

- Yeah.

- And it still can pick up momentum if we,

if we have the right people doing the right things,

and it isn't necessarily gonna go on the educational.

There's a lot of other outlets that can gather communities.

Gaming, for example, is one I've been thinking about.

But it needs, you know,

ultimately you don't get anywhere without motivated people,

and that's what drives communities.

You motivate people who in turn motivate, you know,

get other people are engaging in some way.

And, you know, any of those people

are gonna have upsides and downsides,

and you get both of them from their activities.

That's kind of what they engage with

and where they head is kind of part of it too.

- Yeah.

- Yeah, my sense with APL is that it,

to start with, it has the history.

So it's got the, prior to J,

there were things being developed with APL.

It's got the companies that were running APL.

There's got the, now the different versions

that are coming out that are all sort of based

on the granddaddy, which was APL.

- Well, it's not just now.

I mean, APL has had fragmentation

all through its history.

- Yeah.

- You know, because of the requirement

for custom keyboards and custom displays,

and because back in the mainframe era,

they were selling hardware,

and the software was just like a promotional feature,

a kind of a, you know, like,

I don't know what a good analogy would be

for in today's market, but--

- Loss leader.

- Yeah, a little bit of a loss leader

up until some legal actions

that temporarily gave it some legs.

Anyways, a lot of issues there.

And I'm still remembering, what was it,

Honeywell's APL, where quad I/O was an E wheel number,

which meant you could do quad I/O equals pi,

and then your first index in your A was 3.1.

- Oh, oh, like, like Perl, you can change the first index.

Oh, yeah, yeah, yeah, yeah.

- Well, a lot of the APLs still give you an option

of changing the index origin between one and zero anyway.

- Yeah, I think APL traditionally has quad I/O,

and it's, you know, most of them, it's a zero, one,

but Honeywell decided they were gonna generalize it,

be more powerful.

(laughing)

To this day, it's, anybody that remembers it remembers that.

(laughing)

- Yeah, yeah.

- More power, maybe.

- Well, for geometry, it'd be very interesting, right?

- For, if you're not doing array indices,

it's, you know, you can, it's kind of a fun thing,

but once you get into having code that makes sense,

I mean, you can probably get used to it,

you always assign quad I/O

whenever you're working with array indices,

and then shoot whoever breaks that rule, you know, whatever.

(laughing)

- Or just have a constant division by 3.14

whenever you have to.

(laughing)

Whatever, however many number of significant digits

they give you, five or whatever, just divide by that

so you get back to one.

- Well, you know, I remember also hearing

that in the original APL definition,

you know, Iverson's original concept,

there wasn't any requirement that array indices be integer.

You know, it was like a sparse array concept

that integer just kind of happened to fall out of the math

for the typical case.

But, 'cause they were working on machines

with like 32K memory, they didn't really implement that,

and then the habit stuck.

- Yeah.

So you could kind of do a Dewey decimal system

of inserting in between by just extending the mantissa.

- I mean, conceptually, I mean, it was a chalkboard thing,

so you can do whatever you want.

And then the next lesson, you don't do that anymore

because you're on the chalkboard

and you're doing a different concept.

(laughing)

- Yeah.

Anyway, that's about all I've got.

You gave me lots to think about,

and I should be thinking about it.

(laughing)

And I hadn't been leaning so much,

I was still leaning towards the grid,

but I may actually lean more heavily on the SVG

because there is a lot of things that SVG can do.

And I'll just have to check to see

whether you can template an SVG within the wiki.

I mean, you can put SVG in a template, right?

That's all you would need.

- I think you could be able to, I haven't tried it before,

but you should be able to.

- I would definitely encourage you

to focus on an SVG implementation of something cool.

I think that would be a lot more fun.

- Yeah, yeah.

- With spending a week on anyway.

- Yeah, that's probably true.

I keep my attention a little easier

being the goofy guy that I am.

- Well, you're the SVG hacker.

- That is exactly what I am.

I'm a hacker at SVG.

- Yeah, but it clearly, that's what SVGs are for.

I mean, it's a language.

- Yeah.

- It's an extensive language

and an extensive language is not something

that you can do a complete exploration of the entire space.

So you wind up being a hacker.

- Therefore you hack, yeah, exactly.

- Yeah, and there are areas that I've become aware of

that I've only barely explored,

but the power of the thing is undeniable.

(laughs)

Get your hands, if you can get control of the reins,

you can make it do a lot of very cool things.

Including, I was just thinking the way to do it.

I was wondering whether maybe the way to do it

is don't worry about trying to show everything

in a fixed page, just make it a viewport

and you can move around it.

- Yeah.

I would look into whether people have done

SVG dendrogram algorithms and SVG tree map algorithms,

'cause it's possible you could save yourself a little time,

at least with exploration.

Don't necessarily assume that you have to hack

the whole thing yourself.

- Yeah, no, that's good advice.

I've been on the wrong side of that one a number of times.

- We all have.

- Sometimes you find neat stuff,

but other times you think this would have been

so much better if somebody who knew how to program.

Oh, they did.

Oh, good.

I should have used that.

- Good, yes, exactly.

Exactly, exactly.

- Anyway, that's about all I got.

- Okay, that's it for me too.

- Yeah, anything else?

- Thank you both very much.

Yeah.

- I've got some other stuff I wanna talk about,

but I wanna be, we'll fix a few problems before I do.

So maybe next time.

- Okay, cool.

All right, thank you both.

Take care.

- You as well.

Go Canucks go.

- Go Canoocks go.

You know, you're not allowed to say that.

I used the term Canuck in an article once

and I got some very negative feedback.

- Well, he's allowed to say it,

but you're not allowed to.

See, it's-

- Yeah, exactly, exactly.

That was born upon me.

- Yeah, this goes back to 1994,

the first time they were actually serious contender

for the Stanley Cup.

Somebody in New York, they were talking to them

and they actually, I guess it was probably just

people doing out in the streeters.

How do you pronounce the hockey team from Vancouver?

And most people from New York say Canuck.

- Canuck.

- Nobody says Canoock in Canada.

It's the Canucks, the Canuckleheads.

- Canuck.

- Yeah.

- Canuckleheads, sorry.

- Canucklehead, yeah.

(laughing)

- Something else I'm not allowed to say.

All right, take care.

(laughing)

- Okay, bye-bye.

- Bye-bye.

[end]

Retrieved from "https://code.jsoftware.com/mediawiki/index.php?title=Wiki/Report_of_Meeting_2024-04-18&oldid=49548"