Only topics whose questioners were present were discussed, so we didn't
talk about the interpreter only approach, holding it as a topic for
future session.
Alex addressed the "array avoidance" question, explaining the how arrays
would complicate the core single data type implementation and approach
of picolisp (that single data type being the cell). Further he talked
about how most approaches that in other languages fall to arrays by
default can be handled through picolisp lists, or creating more purpose
built data structures rather than reaching for an array. Finally he
showed how picolisp's native code interface can be used to malloc a
section of heap memory and address it directly to create a direct access
array like structure if that is absolutely required.
Then the question of how picolisp interacts with Java was discussed, and
Alex showed examples in the Pilbox, and showed the named pipe mechanism
used to send commands to the Java side and receive responses back to the
picolisp world.
Olaf showed off his experimentation of using picolisp to communicate
with JavaScript running in a browser to dynamically update SVG objects,
creating animation. Olaf & Alex dug into some of the issues in the
original experiment, and one source of problems was that the ServerEvent
facility that Olaf was using only sends a single line at time to the
other side.
Olaf's motto for the evening: "when you read the picolisp documentation,
you have to read every word"
There may have a been a few other small topics that I am failing to
recollect.
-wilhelm
On 11/6/20 8:03 AM, C K Kashyap wrote:
As bad an excuse that it may sound, it is the truth - I messed up my
alarm setting (AM vs PM) :) and missed the meeting.
Could I request someone to please summarize what was discussed?
particularly about the "interpreter only" approach. If it was not
discussed then perhaps I can request Alex to write down his thoughts.
Regards,
Kashyap
On Thu, Nov 5, 2020 at 2:59 PM Kevin Ednalino <kcednal...@gmail.com
<mailto:kcednal...@gmail.com>> wrote:
Personally, I work business hours so Friday mornings I'm generally
unavailable (GMT).
I think at least one on the weekday in the afternoon/evening and
one on the weekend might be the most convenient with the latter
more convenient for non-European timezones. For example, if it's
hosted on Saturday at noon then it'd be roughly morning for the
Americas and evening for Asia.
If doing 2x meetings a month, then alternating each month with the
weekday/weekend day might maximize availability like if someone is
busy during the week and/or busy during the weekend (if busy both
times, just have to wait untill the next meeting!):
Month: Week 1 / Week 2
Nov: Wed/Sat
Dec: Fri/Sun
Jan: Wed/Sat
...
Or even alternate just weekends weekly between Saturday and Sunday.
On Thu, Nov 5, 2020 at 6:42 PM Alexander Burger
<a...@software-lab.de <mailto:a...@software-lab.de>> wrote:
On Thu, Nov 05, 2020 at 01:23:13PM -0500, r cs wrote:
> Raw video would be welcomed. The timing of the PilCon can
be challenging
> in some time zones.
Independent of the recording issue, the current scheduling is
not an absolute
must. I did a proposal initially, and nobody complained, so we
stayed with it.
Should we consider a change for the future? Perhaps Saturday
would be better
than Friday? And/or some other UTC time(s)? Should we try some
democratic
decision process?
☺/ A!ex
--
UNSUBSCRIBE: mailto:picolisp@software-lab.de
<mailto:picolisp@software-lab.de>?subject=Unsubscribe
