Report of the J Wiki Meeting of February 29, 2024

[robert therriault]

== Report of Meeting 2024-02-29 ==

Present: Art Anger, Skip Cave, Raul Miller, and Bob Therriault

Full transcripts of this meeting are now available on the its wiki page. https://code.jsoftware.com/wiki/Wiki/Report_of_Meeting_2024-02-29

1) A thank you to Skip for providing access to a recent Gemini AI presentation https://drive.google.com/file/d/1KpW33ztSKDI1lbKjyb-o_Ld0yXLSQLMo/view. In the future Large language models (LLM's) may provide a better level of access to the J Wiki. In order to provide better responses Gemini can be based on 'grounded' in specific J sources to provide more reliable information. Gemini can be used to generate answer in a web search with citations or as a chatbot. Skip pointed out that the LLM is most useful because it is able to interpolate the user's search terms which can be an obstacle to newcomers. There is a cost with this, but other open source approaches may be able to achieve similar results, albeit with more work required. Gemini's model uses the initial LLM and then does daily training on the 'grounded' information to keep the information up to date. Skip felt that weekly updates would be all that would be required for the wiki. Bob pointed out that there may be times around version releases that might need more frequent updates. Jon Udell wrote a series of blog posts on incorporating LLM's into programming tools. https://thenewstack.io/author/jon-udell/ . Skip wondered if there were a way to recoup costs by charging a fee for a J chatbot. Raul pointed out that the limited amount of J code may restrict the success of this venture.

2) Raul talked about how the array languages had an advantage initially because the language was tightly integrated to the hardware. Now there is a much wider gulf between hardware and the language implementation with the introduction of GPU's and array processors that require specific programming techniques to take advantage of parallelism. Skip wondered if there was a way to link the J language to the CUDA languages that NVIDIA uses. Raul pointed out that there is limited documentation for adapting J to NVIDIA hardware. In the past J has been designed to connect to other communities, but Raul is unaware of how J could be bound to CUDA. It may be something worth investigating. According to Skip, CUDA compiles to an LLVM compiler that Raul feels J would not compile to. Raul feels the commercial barriers that come with CUDA oppose integration with J. The J language has been developing toward trying parallelize through CPU's and threads. Skip mentioned that the top end NVIDIA chip has 16 thousand cores. These might be used for training LLM's, but would not be necessary to run the LLM. The updating of the J interface to an LLM might be done on a personal computer along the lines of how Ed is generating the SQLite to provide a database for the J Viewer.

3) Bob had spent some time with the CSS Grid tool that Raul had suggested and replicated the Foreigns 9!: https://code.jsoftware.com/mediawiki/index.php?title=Vocabulary/Foreigns/9&action=edit page with a much easier layout style https://code.jsoftware.com/mediawiki/index.php?title=User:Bob_Therriault/9!:0&action=edit. This may make maintenance a lot easier compared to some of the tables we have been working with. Raul felt that this could have been a change rather than maintaining tow versions although Bob had taken more of a prototyping approach. Bob also had included tables of contents and category tree display as content within the grid. https://code.jsoftware.com/wiki/User:Bob_Therriault/Div this allows the display to be more responsive and also keeps elements of the grid centred no matter what the size of some of the elements.

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:59 (UTC) Next meeting is March 7, 2024.

[Jan-Pieter Jacobs]

I'd like to make these comments:

Re point 2):

There is the math/arrayfire addon which allows targetting openCL and CUDA. When I tried it, I found it quite impressive, even if I don't have a CUDA GPU and the addon was still a bit rough at that time. I can imagine someone smarter than me could come up with a transpiler for converting a subset of J code to code using ArrayFire for speeding up performance-critical or computation-heavy code.

Re point 3): I'm all for simplification, but the CSS tables are unreadable on mobile devices (at least for Chrome on my Android phone) as somehow it seems to make text overlapping. The original wiki tables (e.g. for foreigns) were not easy to read either, but at least text was not overlapping.

As we're discussing this, I'd also like to note that in e.g. the foreigns table, in the mobile rendering on Chrome for Android, there are some weird differences in text size that make them hard to read. These are not present when reading the same page in a Linux/Windows browser.

Aside of this, I also noted the same for code snippets, in which the characters only show like half as high as the normal text.

Jan-Pieter

--
To unsubscribe from this group and stop receiving emails from it, send an email to forum+un...@jsoftware.com.

[Raul Miller]

I need to spend more time with arrayfire, I guess. My impression was
that it was useful but not seamless. It would be great if we could
incorporate arrayfire the language implementation in a seamless and
useful way (much like avx2 support)

As for the text overlap thing: I think this is more of a testing issue
than anything else. I did a quick look but the grid examples I was
looking at didn't get text overlap on the mobile device I was looking
at. Could you point me in the right direction (problematic page, and
problematic mobile device)?

Thanks,

--
Raul

[Jan-Pieter Jacobs]

Indeed, at the moment, the ArrayFire plugin is far from seemless. That and the occasional crashes I had playing around with it was why I called it "rough".

For the unreadable text: this is the page with the new CSS being rendered badly on Google Chrome on my Samsung A52 5g s on Android 14, OneUI 6: https://code.jsoftware.com/wiki/Vocabulary/Foreigns/9

Hoping it comes through, I attach a screenshot of how it shows to me.

The inconsistent text sizes present for instance on this page (see the other screenshot): https://code.jsoftware.com/wiki/Vocabulary/Foreigns

It seems the normal text size is increased ( with respect to e.g. the outline of the content, side bar, and some other text in the table). 

On this page, for example, the syntax-highlighted code samples are small, while the ones in <pre> tags is the same size as the text: https://code.jsoftware.com/wiki/ShareMyScreen/AdventOfCode/2022/07/NoSpaceLeftOnDeviceJP

Thanks,

Jan-Pieter

[robert therriault]

Jan-Pieter,

Could you take a look at this page and see if it has similar issues. https://code.jsoftware.com/wiki/User:Bob_Therriault/9!:0 The CSS is slightly different, but Grid is still used to align the items.

Looking at the "Can I Use" site, it suggests that Grid should be supported since Chrome Android version 122. It would be useful to know the version of Android you have.

Thanks for your feedback. It is invaluable in trying to make the J Wiki as accessible as possible.

Cheers, bob

> <Screenshot_20240307_190956_Chrome.jpg><Screenshot_20240307_191912_Chrome.jpg>

[Raul Miller]

I think I have fixed the issue with
https://code.jsoftware.com/wiki/Vocabulary/Foreigns/9

(I am not sure, though, because earlier when I was looking at it, it
did not exhibit the problem - though some other things were also
acting up, ... but, anyways, I'd like to verify that it's not fixed.)

Thanks,

--
Raul

[Jan-Pieter Jacobs]

Hi Bob,

Well thank you for all the effort you put into the J wiki.

That page has the same problem; it seems that the width of the table is constricted to the viewport size, instead of expanding as needed. Because the table does not have enough space, text in the colums starts overlapping.

The problem is not there if I use my phone in portrait mode.

I'm on Android 14, Chrome version 122.0.6261.105 (Official Build) (64-bit).

Cheers,

Jan-Pieter

[robert therriault]

Interesting,

Raul thinks that it may be solved with a nowrap CSS property, but from what you are describing the letters overlapping would be consistent with the grid view because grid does use the viewport as a reference. How zoomed in are you on the text and does zooming out a bit solve the issue?

I will be working on other options tomorrow. Another page I have started to work on is this one. https://code.jsoftware.com/wiki/User:Bob_Therriault/Newcomers The top 4 elements are in a grid and when I look at it on my phone in portrait the elements all fit. The sections below the text box have yet to be put into a grid, so who knows what they will look like.

Anyway thanks again for the report, we'll do our best to get it displaying better. It is heartening to know that it can be intelligible in landscape mode.

Cheers, bob

[Jan-Pieter Jacobs]

Hi Raul,

Your fix seems to work mostly; no more overlapping text, also not in portrait mode.

The table is, however, kept more narrow than needed, and the text is seemingly scaled down accordingly, to quite a tiny font.

It's definitely more usable than before though.

Jan-Pieter

[Raul Miller]

On Fri, Mar 8, 2024 at 3:31 AM Jan-Pieter Jacobs
<janpiete...@gmail.com> wrote:
> The table is, however, kept more narrow than needed, and the text is seemingly scaled down accordingly, to quite a tiny font.

When I visit it on my phone, I see the first two columns have a tiny
font, but not the descriptive column looks fine.

When I visit in chrome, and use its phone emulator, I initially get
similar behavior, but when I try to figure out what's wrong, it starts
to act up on me. (Switching resolutions stops working, the font stops
being different, and my experiments using different font
specifications seem to have no effect.)

I've made a couple changes to enforce the idea that these columns
should be aligned with each other and the same size, but those changes
had no effect when I tested them on my phone.

I'm beginning to think that this is an error in some underlying part
of the implementation of the chromium code base. The quirky behavior I
experienced from the emulator tends to reinforce that point of view.
But I have no idea how to report this kind of issue to someone
responsible. (It may even be that there is no one responsible who can
take action here.)

So... I'm not sure how to proceed.

Still, thanks for the report. Maybe we'll think of something.

--
Raul