Re: PilCon 2020

[Alexander Shendi (Web.DE)]

Hi,

I would actually prefer to attend in person, but given the circumstances, +1 
for an online event.

Best Regards,

-- Alexander

Am 22. April 2020 22:44:35 MESZ schrieb Brian Cleary :
>+1 for online lurker.  I'd also be happy to participate any load tests
>before hand.
>
>On Wed, Apr 22, 2020 at 1:37 PM r cs  wrote:
>
>> +1 for online too 8-)
>>
>> On Wed, Apr 22, 2020 at 12:33 PM C K Kashyap 
>wrote:
>>
>>> +1 for online :)
>>>
>>> On Wed, Apr 22, 2020 at 4:48 AM David Bloom 
>wrote:
>>>
 +1 lurker interested in an online conference. While it is
>disappointing
 to not be able to meet people in person it seems that attendance
>will be
 dramatically increased.  Happy to help with testing online tools if
>needed.

 On Wed, Apr 22, 2020, 1:35 AM Jean-Christophe Helary <
 jean.christophe.hel...@traduction-libre.org> wrote:

>
>
> > On Apr 22, 2020, at 14:00, Alexander Burger
>
> wrote:
> >
> > Would it make sense to plan an online conference instead? We are
> playing around
> > with Jitsi Meet currently. Any thoughts?
>
> You must be aware that the FSF's LibrePlanet was moved from IRL to
> Jisti (and others) in just a few days of time. In my personal
>business,
> I've moved all my IRL interactions to Jisti. I find it very
>practical.
>
> Last night I just had a QA/live support session for a piece of
>free
> software that I'm involved with. There were setting issues that
>probably
> were personal technical issues but otherwise the meeting went very
>smoothly.
>
> The ability to stream Youtube for already registered presentations
>is
> something that could definitely be of use in a conference, leaving
>the live
> part for the Q
>
> Also, as a "lurker" and very amateur programer, I would never
>think of
> joining PilCon in Germany, but I'd love to attend if it were
>online. I am
> sure a lot of people interested in other dialects of Lisp would
>find it
> easier to join too.
>
>
> Jean-Christophe Helary
> ---
> http://mac4translators.blogspot.com @brandelune
>
>
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe
>

>>
>> --
>> *Níl aon tinteán mar do thinteán féin. *[Irish Gaelic]
>> (There is no fireside like your own fireside.)
>>
>>
>>

--
You have zero privacy anyway. Get over it.

Scott McNealy 1999

Re: PilCon 2020

[Brian Cleary]

+1 for online lurker.  I'd also be happy to participate any load tests
before hand.

On Wed, Apr 22, 2020 at 1:37 PM r cs  wrote:

> +1 for online too 8-)
>
> On Wed, Apr 22, 2020 at 12:33 PM C K Kashyap  wrote:
>
>> +1 for online :)
>>
>> On Wed, Apr 22, 2020 at 4:48 AM David Bloom  wrote:
>>
>>> +1 lurker interested in an online conference. While it is disappointing
>>> to not be able to meet people in person it seems that attendance will be
>>> dramatically increased.  Happy to help with testing online tools if needed.
>>>
>>> On Wed, Apr 22, 2020, 1:35 AM Jean-Christophe Helary <
>>> jean.christophe.hel...@traduction-libre.org> wrote:
>>>


 > On Apr 22, 2020, at 14:00, Alexander Burger 
 wrote:
 >
 > Would it make sense to plan an online conference instead? We are
 playing around
 > with Jitsi Meet currently. Any thoughts?

 You must be aware that the FSF's LibrePlanet was moved from IRL to
 Jisti (and others) in just a few days of time. In my personal business,
 I've moved all my IRL interactions to Jisti. I find it very practical.

 Last night I just had a QA/live support session for a piece of free
 software that I'm involved with. There were setting issues that probably
 were personal technical issues but otherwise the meeting went very 
 smoothly.

 The ability to stream Youtube for already registered presentations is
 something that could definitely be of use in a conference, leaving the live
 part for the Q

 Also, as a "lurker" and very amateur programer, I would never think of
 joining PilCon in Germany, but I'd love to attend if it were online. I am
 sure a lot of people interested in other dialects of Lisp would find it
 easier to join too.


 Jean-Christophe Helary
 ---
 http://mac4translators.blogspot.com @brandelune



 --
 UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe

>>>
>
> --
> *Níl aon tinteán mar do thinteán féin. *[Irish Gaelic]
> (There is no fireside like your own fireside.)
>
>
>

Re: PilCon 2020

[r cs]

 +1 for online too 8-)

On Wed, Apr 22, 2020 at 12:33 PM C K Kashyap  wrote:

> +1 for online :)
>
> On Wed, Apr 22, 2020 at 4:48 AM David Bloom  wrote:
>
>> +1 lurker interested in an online conference. While it is disappointing
>> to not be able to meet people in person it seems that attendance will be
>> dramatically increased.  Happy to help with testing online tools if needed.
>>
>> On Wed, Apr 22, 2020, 1:35 AM Jean-Christophe Helary <
>> jean.christophe.hel...@traduction-libre.org> wrote:
>>
>>>
>>>
>>> > On Apr 22, 2020, at 14:00, Alexander Burger 
>>> wrote:
>>> >
>>> > Would it make sense to plan an online conference instead? We are
>>> playing around
>>> > with Jitsi Meet currently. Any thoughts?
>>>
>>> You must be aware that the FSF's LibrePlanet was moved from IRL to Jisti
>>> (and others) in just a few days of time. In my personal business, I've
>>> moved all my IRL interactions to Jisti. I find it very practical.
>>>
>>> Last night I just had a QA/live support session for a piece of free
>>> software that I'm involved with. There were setting issues that probably
>>> were personal technical issues but otherwise the meeting went very smoothly.
>>>
>>> The ability to stream Youtube for already registered presentations is
>>> something that could definitely be of use in a conference, leaving the live
>>> part for the Q
>>>
>>> Also, as a "lurker" and very amateur programer, I would never think of
>>> joining PilCon in Germany, but I'd love to attend if it were online. I am
>>> sure a lot of people interested in other dialects of Lisp would find it
>>> easier to join too.
>>>
>>>
>>> Jean-Christophe Helary
>>> ---
>>> http://mac4translators.blogspot.com @brandelune
>>>
>>>
>>>
>>> --
>>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe
>>>
>>

-- 
*Níl aon tinteán mar do thinteán féin. *[Irish Gaelic]
(There is no fireside like your own fireside.)

Re: PilCon 2020

[C K Kashyap]

+1 for online :)

On Wed, Apr 22, 2020 at 4:48 AM David Bloom  wrote:

> +1 lurker interested in an online conference. While it is disappointing to
> not be able to meet people in person it seems that attendance will be
> dramatically increased.  Happy to help with testing online tools if needed.
>
> On Wed, Apr 22, 2020, 1:35 AM Jean-Christophe Helary <
> jean.christophe.hel...@traduction-libre.org> wrote:
>
>>
>>
>> > On Apr 22, 2020, at 14:00, Alexander Burger 
>> wrote:
>> >
>> > Would it make sense to plan an online conference instead? We are
>> playing around
>> > with Jitsi Meet currently. Any thoughts?
>>
>> You must be aware that the FSF's LibrePlanet was moved from IRL to Jisti
>> (and others) in just a few days of time. In my personal business, I've
>> moved all my IRL interactions to Jisti. I find it very practical.
>>
>> Last night I just had a QA/live support session for a piece of free
>> software that I'm involved with. There were setting issues that probably
>> were personal technical issues but otherwise the meeting went very smoothly.
>>
>> The ability to stream Youtube for already registered presentations is
>> something that could definitely be of use in a conference, leaving the live
>> part for the Q
>>
>> Also, as a "lurker" and very amateur programer, I would never think of
>> joining PilCon in Germany, but I'd love to attend if it were online. I am
>> sure a lot of people interested in other dialects of Lisp would find it
>> easier to join too.
>>
>>
>> Jean-Christophe Helary
>> ---
>> http://mac4translators.blogspot.com @brandelune
>>
>>
>>
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe
>>
>

Re: MiniPicolisp Questions

[C K Kashyap]

oops .. hit send too early -
Got it. The idea was not to encode more types - just reduce the
"complexity" of tagged pointers and remove the word aligned function
address restriction. Yes, a separate byte heap would totally be much more
complex. One of the reasons of this desire was to build miniPicoLis with
TCC :) which does not seem to generate WORD aligned function addresses. The
second reason for this desire was to have a system for "instructive"
purposes - where it seems that doubling the space may not be such a bad
idea. The wasted space would be clearly visible and perhaps help with the
appreciation for the tagged pointer as an optimization.

But yes, I can clearly see that a 9byte cell is not a good idea :)

On Wed, Apr 22, 2020 at 8:27 AM C K Kashyap  wrote:

> Got it. The idea was not to encode more types - just reduce the
> "complexity" of tagged pointers and impose the word aligned function
> address restriction but from what I gather. Yes, a separate byte heap would
> totally be much ore complex. One of the reasons of this desire was to build
> miniPicoLis with TCC :) which does not seem to generate WORD
> aligned function addresses. The second reason for this desire was to have a
> system for "instructive" purpose - where it seems that doubling the space
> may not be such a bad idea. The wasted space would be clearly visible and
> perhaps help with the appreciation for the tagged pointer as an
> optimization.
>
> But yes, I can clearly see that a 9byte cell is not a good idea :)
>
> Regards,
> Kashyap
>
> On Wed, Apr 22, 2020 at 7:28 AM Alexander Burger 
> wrote:
>
>> Hi Kashyap,
>>
>> > Quick question - when you mentioned "doubling of space" - perhaps you
>> were
>> > talking about systems that can only have WORD aligned pointers - is that
>> > correct?
>>
>> Not only. Also on a byte-addressed machine, imagine if you make a cell of
>> two
>> 9-byte words, you get every cell aligned at another offet, with terrible
>> performance. On most machines you will get a bus error anyway.
>>
>> So my second proposal was to use a separate heap of bytes. But this also
>> gets
>> extremely uncomfortable and inefficient, as you need to index into two
>> heaps for
>> each access. You won't get a simpler system, as you intended.
>>
>> And what to do with that byte? Encode more types than fit into the 4 bits
>> in
>> Pil? Then you must also interprete those types at runtime during
>> interpretation.
>> Seems you open a pandora box ;)
>>
>> ☺/ A!ex
>>
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>>
>

Re: MiniPicolisp Questions

[C K Kashyap]

Got it. The idea was not to encode more types - just reduce the
"complexity" of tagged pointers and impose the word aligned function
address restriction but from what I gather. Yes, a separate byte heap would
totally be much ore complex. One of the reasons of this desire was to build
miniPicoLis with TCC :) which does not seem to generate WORD
aligned function addresses. The second reason for this desire was to have a
system for "instructive" purpose - where it seems that doubling the space
may not be such a bad idea. The wasted space would be clearly visible and
perhaps help with the appreciation for the tagged pointer as an
optimization.

But yes, I can clearly see that a 9byte cell is not a good idea :)

Regards,
Kashyap

On Wed, Apr 22, 2020 at 7:28 AM Alexander Burger 
wrote:

> Hi Kashyap,
>
> > Quick question - when you mentioned "doubling of space" - perhaps you
> were
> > talking about systems that can only have WORD aligned pointers - is that
> > correct?
>
> Not only. Also on a byte-addressed machine, imagine if you make a cell of
> two
> 9-byte words, you get every cell aligned at another offet, with terrible
> performance. On most machines you will get a bus error anyway.
>
> So my second proposal was to use a separate heap of bytes. But this also
> gets
> extremely uncomfortable and inefficient, as you need to index into two
> heaps for
> each access. You won't get a simpler system, as you intended.
>
> And what to do with that byte? Encode more types than fit into the 4 bits
> in
> Pil? Then you must also interprete those types at runtime during
> interpretation.
> Seems you open a pandora box ;)
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: MiniPicolisp Questions

[Guido Stepken]

Nope. Polymorphic Inline Caching. And why shouldn't JIT compilers use MMU
"memory address violation exception" to check for end of range? Same for
TLB.

I could flood you with hundreds of papers about that. I am using that all
time.

Of you were right and such knowledgeable, PicoLisp would run fast. But it
doesn't. So take my pointers and - learn something new! ;-)

Best regards, Guido

Am Mittwoch, 22. April 2020 schrieb Alexander Burger :
> On Wed, Apr 22, 2020 at 03:49:41PM +0200, Guido Stepken wrote:
>> Well, we have year 2020, not Dijksra 1978. Even embedded systems have a
MMU
>> and you get "Memory Access Violation", so no pointer rage checks needed
to
>> be handled by CPU any longer.
>
> Sigh, you don't understand at all how a Lisp interpreter works.
> It is *all* type checks. We have dynamic data. Please stop
> talking about things you have no clue of!
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: MiniPicolisp Questions

[Alexander Burger]

Hi Kashyap,

> Quick question - when you mentioned "doubling of space" - perhaps you were
> talking about systems that can only have WORD aligned pointers - is that
> correct?

Not only. Also on a byte-addressed machine, imagine if you make a cell of two
9-byte words, you get every cell aligned at another offet, with terrible
performance. On most machines you will get a bus error anyway.

So my second proposal was to use a separate heap of bytes. But this also gets
extremely uncomfortable and inefficient, as you need to index into two heaps for
each access. You won't get a simpler system, as you intended.

And what to do with that byte? Encode more types than fit into the 4 bits in
Pil? Then you must also interprete those types at runtime during interpretation.
Seems you open a pandora box ;)

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: MiniPicolisp Questions

[C K Kashyap]

Hi Alex,
Quick question - when you mentioned "doubling of space" - perhaps you were
talking about systems that can only have WORD aligned pointers - is that
correct?
Regards,
Kashyap


On Wed, Apr 22, 2020 at 6:56 AM Guido Stepken  wrote:

> Well, we have year 2020, not Dijksra 1978. Even embedded systems have a
> MMU and you get "Memory Access Violation", so no pointer rage checks needed
> to be handled by CPU any longer. Those formerly needed range checks, eating
> up clock cycles, now are deeply sticking in MMU and IOMMU ... Bang! -
> Exception!
>
> Also reading about modern "multi generational garbage collectors" will
> explain, why garbage collected (functional, pure OO) languages have kept up
> with C/C++ statically machine code. Julia language, sitting on FemtoLisp
> JIT engine, in some times even ist faster than C
>
> Have fun!
>
> Am Mittwoch, 22. April 2020 schrieb Alexander Burger  >:
> > Hi Geo,
> >
> >> I think you mean 0xF000 for everything? This is indeed cool! but hmm
> does
> >> it limit the memory for each data type?
> >
> > Yes, what Guido writes is nonsense. Fixed-sized address spaces are a
> terrible
> > solution. Doesn't scale, and is extremely inefficient due to the
> necessary
> > pointer range checks.
> >
> > PicoLisp's way is far superior, because the tag bits come "free", they
> are
> > implicit by the natural pointer alignments.
> >
> > ☺/ A!ex
> >
> > --
> > UNSUBSCRIBE: mailto:picolisp@software-labde 
> ?subject=Unsubscribe
> >
> >

Re: MiniPicolisp Questions

[Alexander Burger]

On Wed, Apr 22, 2020 at 03:49:41PM +0200, Guido Stepken wrote:
> Well, we have year 2020, not Dijksra 1978. Even embedded systems have a MMU
> and you get "Memory Access Violation", so no pointer rage checks needed to
> be handled by CPU any longer.

Sigh, you don't understand at all how a Lisp interpreter works.
It is *all* type checks. We have dynamic data. Please stop
talking about things you have no clue of!

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: MiniPicolisp Questions

[Guido Stepken]

Well, we have year 2020, not Dijksra 1978. Even embedded systems have a MMU
and you get "Memory Access Violation", so no pointer rage checks needed to
be handled by CPU any longer. Those formerly needed range checks, eating up
clock cycles, now are deeply sticking in MMU and IOMMU ... Bang! -
Exception!

Also reading about modern "multi generational garbage collectors" will
explain, why garbage collected (functional, pure OO) languages have kept up
with C/C++ statically machine code. Julia language, sitting on FemtoLisp
JIT engine, in some times even ist faster than C.

Have fun!

Am Mittwoch, 22. April 2020 schrieb Alexander Burger :
> Hi Geo,
>
>> I think you mean 0xF000 for everything? This is indeed cool! but hmm does
>> it limit the memory for each data type?
>
> Yes, what Guido writes is nonsense. Fixed-sized address spaces are a
terrible
> solution. Doesn't scale, and is extremely inefficient due to the necessary
> pointer range checks.
>
> PicoLisp's way is far superior, because the tag bits come "free", they are
> implicit by the natural pointer alignments.
>
> ☺/ A!ex
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>
>

Re: MiniPicolisp Questions

[George-Phillip Orais]

Hi Alex,

> Yes, what Guido writes is nonsense. Fixed-sized address spaces are a
terrible
> solution. Doesn't scale, and is extremely inefficient due to the necessary
> pointer range checks.
>
> PicoLisp's way is far superior, because the tag bits come "free", they are
> implicit by the natural pointer alignments.

I see, that make sense, thank you for the explanation.


Hi Guido,

> I meat: "0xE000 for everything, that must be persisted to disk". There,
of course, you can also reserve three slots for float, integer, string ...

If so, will it conflict with strings? Anyway thanks for sharing your
thoughts, its nice to know other approach existed, we look forward to see
your ASIC LispM someday soon..


BR,
Geo

Re: MiniPicolisp Questions

[Guido Stepken]

I meat: "0xE000 for everything, that must be persisted to disk". There, of
course, you can also reserve three slots for float, integer, string ...

Best regards, Guido

Am Mittwoch, 22. April 2020 schrieb George-Phillip Orais <
orais.georgephil...@gmail.com>:
> Hi Guido,
> I think you mean 0xF000 for everything? This is indeed cool! but hmm does
it limit the memory for each data type? Like what if the application uses
only integers so does it mean it cannot use the memory location for float
and strings?
>
> BR,
> Geo
> On Wed, Apr 22, 2020 at 8:44 PM Guido Stepken  wrote:
>>
>> Hi Kashyap!
>>
>> Reserving 1-3 bit from 32 or 64 bit register for special purposes, e.g.
indicating type or as persistence flag (ORM-wrapper) is the old fashioned
way. It unnecessarily costs cycles, reduces precision ...
>>
>> The modern, "fully functional" (no state bits anywhere!) - and correct -
way would be to indicate type by its position in memory:
>>
>> 0xC000 all floats, 0xD000 all integers, 0xE000 all strings, 0xD000
everything, that have to be persisted do disk. Let another CPU do the
persistence! ;-)
>>
>> Have fun!
>>
>> Best, Guido Stepken
>>
>> Am Mittwoch, 22. April 2020 schrieb C K Kashyap :
>> > Thanks Alex,
>> > I was thinking of increased memory space - not exactly doubling -  I
was thinking it would just be one additional byte per CELL. Ofcourse this
additional byte would not have the same lifetime of the CELL so it should
not need any extra management.
>> > I feel encouraged - I'll give it a try :)
>> > Regards,
>> > Kashyap
>> > On Tue, Apr 21, 2020 at 10:11 PM Alexander Burger 
wrote:
>> >>
>> >> Hi Kashyap,
>> >>
>> >> > About the the CELL having an additional byte, I meant that the CELL
size
>> >> > would be 2*WORD + 1... that should work too right? I would not need
any
>> >> > masking in that case.
>> >>
>> >> I see. Yes, that would work. But it would either double the memory
usage, or
>> >> require some management of this additional byte (e.g. in a separate,
parallel
>> >> byte heap), which complicates things a lot more than it benefits.
>> >>
>> >> ☺/ A!ex
>> >>
>> >>
>> >> --
>> >> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>> >

Re: MiniPicolisp Questions

[Alexander Burger]

Hi Geo,

> I think you mean 0xF000 for everything? This is indeed cool! but hmm does
> it limit the memory for each data type?

Yes, what Guido writes is nonsense. Fixed-sized address spaces are a terrible
solution. Doesn't scale, and is extremely inefficient due to the necessary
pointer range checks.

PicoLisp's way is far superior, because the tag bits come "free", they are
implicit by the natural pointer alignments.

☺/ A!ex

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: MiniPicolisp Questions

[George-Phillip Orais]

Hi Guido,

I think you mean 0xF000 for everything? This is indeed cool! but hmm does
it limit the memory for each data type? Like what if the application uses
only integers so does it mean it cannot use the memory location for float
and strings?


BR,
Geo

On Wed, Apr 22, 2020 at 8:44 PM Guido Stepken  wrote:

> Hi Kashyap!
>
> Reserving 1-3 bit from 32 or 64 bit register for special purposes, e.g.
> indicating type or as persistence flag (ORM-wrapper) is the old fashioned
> way. It unnecessarily costs cycles, reduces precision ...
>
> The modern, "fully functional" (no state bits anywhere!) - and correct -
> way would be to indicate type by its position in memory:
>
> 0xC000 all floats, 0xD000 all integers, 0xE000 all strings, 0xD000
> everything, that have to be persisted do disk. Let another CPU do the
> persistence! ;-)
>
> Have fun!
>
> Best, Guido Stepken
>
> Am Mittwoch, 22. April 2020 schrieb C K Kashyap :
> > Thanks Alex,
> > I was thinking of increased memory space - not exactly doubling -  I was
> thinking it would just be one additional byte per CELL. Ofcourse this
> additional byte would not have the same lifetime of the CELL so it should
> not need any extra management.
> > I feel encouraged - I'll give it a try :)
> > Regards,
> > Kashyap
> > On Tue, Apr 21, 2020 at 10:11 PM Alexander Burger 
> wrote:
> >>
> >> Hi Kashyap,
> >>
> >> > About the the CELL having an additional byte, I meant that the CELL
> size
> >> > would be 2*WORD + 1... that should work too right? I would not need
> any
> >> > masking in that case.
> >>
> >> I see. Yes, that would work. But it would either double the memory
> usage, or
> >> require some management of this additional byte (e.g. in a separate,
> parallel
> >> byte heap), which complicates things a lot more than it benefits.
> >>
> >> ☺/ A!ex
> >>
> >>
> >> --
> >> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
> >

Re: PilCon 2020

[David Bloom]

+1 lurker interested in an online conference. While it is disappointing to
not be able to meet people in person it seems that attendance will be
dramatically increased.  Happy to help with testing online tools if needed.

On Wed, Apr 22, 2020, 1:35 AM Jean-Christophe Helary <
jean.christophe.hel...@traduction-libre.org> wrote:

>
>
> > On Apr 22, 2020, at 14:00, Alexander Burger  wrote:
> >
> > Would it make sense to plan an online conference instead? We are playing
> around
> > with Jitsi Meet currently. Any thoughts?
>
> You must be aware that the FSF's LibrePlanet was moved from IRL to Jisti
> (and others) in just a few days of time. In my personal business, I've
> moved all my IRL interactions to Jisti. I find it very practical.
>
> Last night I just had a QA/live support session for a piece of free
> software that I'm involved with. There were setting issues that probably
> were personal technical issues but otherwise the meeting went very smoothly.
>
> The ability to stream Youtube for already registered presentations is
> something that could definitely be of use in a conference, leaving the live
> part for the Q
>
> Also, as a "lurker" and very amateur programer, I would never think of
> joining PilCon in Germany, but I'd love to attend if it were online. I am
> sure a lot of people interested in other dialects of Lisp would find it
> easier to join too.
>
>
> Jean-Christophe Helary
> ---
> http://mac4translators.blogspot.com @brandelune
>
>
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe
>

Re: MiniPicolisp Questions

[Guido Stepken]

Hi Kashyap!

Reserving 1-3 bit from 32 or 64 bit register for special purposes, e.g.
indicating type or as persistence flag (ORM-wrapper) is the old fashioned
way. It unnecessarily costs cycles, reduces precision ...

The modern, "fully functional" (no state bits anywhere!) - and correct -
way would be to indicate type by its position in memory:

0xC000 all floats, 0xD000 all integers, 0xE000 all strings, 0xD000
everything, that have to be persisted do disk. Let another CPU do the
persistence! ;-)

Have fun!

Best, Guido Stepken

Am Mittwoch, 22. April 2020 schrieb C K Kashyap :
> Thanks Alex,
> I was thinking of increased memory space - not exactly doubling -  I was
thinking it would just be one additional byte per CELL. Ofcourse this
additional byte would not have the same lifetime of the CELL so it should
not need any extra management.
> I feel encouraged - I'll give it a try :)
> Regards,
> Kashyap
> On Tue, Apr 21, 2020 at 10:11 PM Alexander Burger 
wrote:
>>
>> Hi Kashyap,
>>
>> > About the the CELL having an additional byte, I meant that the CELL
size
>> > would be 2*WORD + 1... that should work too right? I would not need any
>> > masking in that case.
>>
>> I see. Yes, that would work. But it would either double the memory
usage, or
>> require some management of this additional byte (e.g. in a separate,
parallel
>> byte heap), which complicates things a lot more than it benefits.
>>
>> ☺/ A!ex
>>
>>
>> --
>> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: PilCon 2020

[Mattias Sundblad]

Hello,

This is sad, but I think it is the most realistic decision under the
circumstances. Let's hope we can arrange something in the future.

I too would be interested in an online conference.

/ Mattias
On Wed, Apr 22, 2020 at 07:00:21AM +0200, Alexander Burger wrote:
> Hi all,
> 
> yesterday the Oktoberfest, the largest annual event in Bavaria, was canceled.
> 
> I think we will also have to cancel the other large event, PilCon. It is not
> sure whether such events will be allowed legally by end of July, and how the
> international travel situation will be.
> 
> I hope this is OK for everybody.
> 
> Would it make sense to plan an online conference instead? We are playing 
> around
> with Jitsi Meet currently. Any thoughts?
> 
> ☺/ A!ex
> 
> -- 
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: PilCon 2020

[cilz]

Hello guys,

I too would be happy to "attend" such a virtual meeting ;-)

Take care, best

Eric

Le 22/04/2020 à 08:13, George-Phillip Orais a écrit :
Same here, as lurker and amateur PicoLisper, I love to join and the 
attend this online PilCon 2020, thank you Alex!



BR,
Geo


-- 
UNSUBSCRIBE: mailto:picolisp@software-lab.de

?subjectUnsubscribe

Re: PilCon 2020

[Wojciech Gac]

Having started my adventure with Lisp conferences in 2018 (ELS 2018 in
Marbella, Spain) I got completely hooked up on the idea of meeting
super-interesting people and listening about stuff they're working
on. I'd be excited to join you guys. Of course, being able to meet in
person beats anything, but given the circumstances, an online
conference is the next best thing, I guess.

Cheers,
Wojtek


On Wed, Apr 22, 2020 at 8:43 AM Wilhelm Fitzpatrick  wrote:

> I'll add my voice as being another who would be interested in an online
> convention.
>
> -Wilhelm
>
> On 4/21/20 11:13 PM, George-Phillip Orais wrote:
> > Same here, as lurker and amateur PicoLisper, I love to join and the
> > attend this online PilCon 2020, thank you Alex!
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
>

Re: PilCon 2020

[andreas]

Hi Jean-Christophe Helary

> There is a thread on hacknews about jisti vs mumble where they mention issues 
> with a large number of people.
>
> https://news.ycombinator.com/item?id=22477785
Thanks for the link. Yeah I think people tested my current instance with
up to 5 people for several hours. Afaik the expected bottleneck on the
server is the internet link.
From what I read, often the client side is running into load problems
with increased number of participants, especially with Firefox.
Apparently their WebRTC implementation is not as optimized as desired.

We should certainly test before the event, and probably I could optimize
some more things on my instance (if that is the bottleneck).
Possible alternatives would surely be Mumble or Teamspeak (no video
streaming, but certainly works for large crowds, I used to use both).

Maybe we should ask presenters to put their slides into LaTex Beam PDF
or HTML format (navigating with arrow keys, e.g.
https://ptrace.fefe.de/hype2 ).
Would have the nice side effect that then it can be downloaded and
viewed at individual speed.

On the other hand, there should be a way to clearly communicate on which
slide the presenter is, without having to tell it every slide.
Could be a little pil app with a special login for the presenter to
select the currently active slide.

- beneroth


On 22.04.20 07:43, Jean-Christophe Helary wrote:
>
>> On Apr 22, 2020, at 14:00, Alexander Burger  wrote:
>>
>> Hi all,
>>
>> yesterday the Oktoberfest, the largest annual event in Bavaria, was canceled.
>>
>> I think we will also have to cancel the other large event, PilCon. It is not
>> sure whether such events will be allowed legally by end of July, and how the
>> international travel situation will be.
>>
>> I hope this is OK for everybody.
>>
>> Would it make sense to plan an online conference instead? We are playing 
>> around
>> with Jitsi Meet currently. Any thoughts?
> There is a thread on hacknews about jisti vs mumble where they mention issues 
> with a large number of people.
>
> https://news.ycombinator.com/item?id=22477785
>
> Maybe it would be nive to do tests with a dozen participants or so before 
> going live ?
>
>
> Jean-Christophe Helary
> ---
> http://mac4translators.blogspot.com @brandelune
>
>
>


--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: PilCon 2020

[Wilhelm Fitzpatrick]

I'll add my voice as being another who would be interested in an online 
convention.


-Wilhelm

On 4/21/20 11:13 PM, George-Phillip Orais wrote:
Same here, as lurker and amateur PicoLisper, I love to join and the 
attend this online PilCon 2020, thank you Alex!


--
UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe

Re: PilCon 2020

[Edgaras Šeputis]

Super lurker here, who just deployed (self hosted) jitsi as part of product
we sell. IMO jitsi is quite good, and if self hosting I would have little
concerns. Also it is not hard to self host with esp with their docker
version, though it currently has a bug with streaming (well due to chrome
dropping flag to not accept insecure certs), which needs ether work around
or just wait a bit, as fix is incoming. All in all it seems good. And can
have big calls, though due to how it all works generally you will not want
to have >10 people sending video, due to network bottlenecks on user side.

On Wed, Apr 22, 2020 at 8:47 AM Jean-Christophe Helary <
jean.christophe.hel...@traduction-libre.org> wrote:

>
>
> > On Apr 22, 2020, at 14:00, Alexander Burger  wrote:
> >
> > Hi all,
> >
> > yesterday the Oktoberfest, the largest annual event in Bavaria, was
> canceled.
> >
> > I think we will also have to cancel the other large event, PilCon. It is
> not
> > sure whether such events will be allowed legally by end of July, and how
> the
> > international travel situation will be.
> >
> > I hope this is OK for everybody.
> >
> > Would it make sense to plan an online conference instead? We are playing
> around
> > with Jitsi Meet currently. Any thoughts?
>
> There is a thread on hacknews about jisti vs mumble where they mention
> issues with a large number of people.
>
> https://news.ycombinator.com/item?id=22477785
>
> Maybe it would be nive to do tests with a dozen participants or so before
> going live ?
>
>
> Jean-Christophe Helary
> ---
> http://mac4translators.blogspot.com @brandelune
>
>
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe
>

Re: PilCon 2020

[George-Phillip Orais]

Same here, as lurker and amateur PicoLisper, I love to join and the attend
this online PilCon 2020, thank you Alex!


BR,
Geo

On Wed, Apr 22, 2020 at 2:47 PM Jean-Christophe Helary <
jean.christophe.hel...@traduction-libre.org> wrote:

>
>
> > On Apr 22, 2020, at 14:00, Alexander Burger  wrote:
> >
> > Hi all,
> >
> > yesterday the Oktoberfest, the largest annual event in Bavaria, was
> canceled.
> >
> > I think we will also have to cancel the other large event, PilCon. It is
> not
> > sure whether such events will be allowed legally by end of July, and how
> the
> > international travel situation will be.
> >
> > I hope this is OK for everybody.
> >
> > Would it make sense to plan an online conference instead? We are playing
> around
> > with Jitsi Meet currently. Any thoughts?
>
> There is a thread on hacknews about jisti vs mumble where they mention
> issues with a large number of people.
>
> https://news.ycombinator.com/item?id=22477785
>
> Maybe it would be nive to do tests with a dozen participants or so before
> going live ?
>
>
> Jean-Christophe Helary
> ---
> http://mac4translators.blogspot.com @brandelune
>
>
>
> --
> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subjectUnsubscribe
>