Re: PilCon 2020
> On Apr 28, 2020, at 15:20, Alexander Shendi (Web.DE) > wrote: > > Dear List, > > My experience using Jitsi with Firefox wasn't good. I tried to attend an > online meeting with FF 71 and I managed to crash the server. Apparently this > is Firefox's fault though for not supporting all necessary features of WebRTC. Try 75. Maybe it is better. > I'd like to use the Jitsi Android app, but I don't know how to use an USB > headset with either my phone or a tablet. Maybe an analog headphone and the > device's microphone is the way to go. An analog headphone should be sufficient. But if you mute your mike during the presentations, there is no real need for a headphone. Jean-Christophe Helary --- http://mac4translators.blogspot.com @brandelune -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: PilCon 2020
> On Apr 28, 2020, at 15:26, Christophe Gragnic > wrote: > > 2) We could organize a «warm up» as it is done in music festivals Definitely. Maybe the day before ? A short rehearsal for all the people who have presentations to see if things work well ? Jean-Christophe Helary --- http://mac4translators.blogspot.com @brandelune -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: PilCon 2020
On Tue, Apr 28, 2020 at 7:44 AM Alexander Burger wrote: > We used Jitsi a lot during the last weeks. I have tried up to only 5 members > so > far, but performance was good. Beneroth has set up his own server. I don't > know > how well it scales for more members, and what can be done to optimize it. Hi, 1) I'm very excited to hear about this idea of virtual gathering. Sorry for those who could have been to a real gathering, but this will allow me to participate. 2) We could organize a «warm up» as it is done in music festivals
Re: PilCon 2020
Dear List,
My experience using Jitsi with Firefox wasn't good. I tried to attend an online
meeting with FF 71 and I managed to crash the server. Apparently this is
Firefox's fault though for not supporting all necessary features of WebRTC.
Unfortunately for me there is no alternative ATM. NetBSD has only FF in
packages (both on aarch64 and amd64). I'd like to use the Jitsi Android app,
but I don't know how to use an USB headset with either my phone or a tablet.
Maybe an analog headphone and the device's microphone is the way to go.
I don't feel up to compiling Chrom{e, ium} myself.
I would be grateful for any hints. TIA.
Love,
-- Alexander
Am 28. April 2020 07:38:06 MESZ schrieb Alexander Burger :
>Hi Tomas,
>
>> > Would it make sense to plan an online conference instead? We are
>playing around
>> > with Jitsi Meet currently. Any thoughts?
>>
>> I tried Jitsi and it seems broken on NixOS (throwing some Java
>exception
>> about a DNS class not found).
>
>We used Jitsi a lot during the last weeks. I have tried up to only 5
>members so
>far, but performance was good. Beneroth has set up his own server. I
>don't know
>how well it scales for more members, and what can be done to optimize
>it.
>
>> Does Jitsi also work in Firefox?
>
>I always used the Jitsi Meet app on Android for audio and video, and
>sometimes
>additionally Firefox on a Debian PC to demonstrate things on a shared
>screen.
>
>☺/ A!ex
>
>--
>UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
--
You have zero privacy anyway. Get over it.
Scott McNealy 1999
Re: PilCon 2020
Hi Tomas, > > Would it make sense to plan an online conference instead? We are playing > > around > > with Jitsi Meet currently. Any thoughts? > > I tried Jitsi and it seems broken on NixOS (throwing some Java exception > about a DNS class not found). We used Jitsi a lot during the last weeks. I have tried up to only 5 members so far, but performance was good. Beneroth has set up his own server. I don't know how well it scales for more members, and what can be done to optimize it. > Does Jitsi also work in Firefox? I always used the Jitsi Meet app on Android for audio and video, and sometimes additionally Firefox on a Debian PC to demonstrate things on a shared screen. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Digging into Symbols
On Mon, Apr 27, 2020 at 02:38:35PM -0700, Wilhelm Fitzpatrick wrote: > > Correct. The first character(s) need to be accessed more prominently. > > > Hmm... because checking the first > byte/character is just a mask, rather than > shift & mask? Yes, but most of all it concerns the first up to 8 characters in the first *cell* of the name. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Stop using US controlled software stacks!!!
China is changing gears, decoupling from TCP/IP protocol. Means: USA becoming isolated. It's a 320 million people state, making just 5% of global population. https://cntechpost.com/2020/03/30/huawei-aims-to-reshape-internet-with-protocol-called-new-ip/ China certainly has long wanted to isolate itself from the rest of the internet, given the propensity for inconvenient truths to leak in that way. And given that they are 1/5th of the world population, perhaps they can do that. That said, not sure we in the rest of the world should be excited about signing up for a new basic layer with "authoritarian ready" features. As much as some factions in the USA would like to become "China Jr.", keeping the sieve leaking is our best path forward to frustrating their ambitions. https://www.engadget.com/2020-03-30-china-huawei-new-ip-proposal.html I might have to look into the actual "New IP" proposal a little further though. I'm curious to see if they built in any "migration path" that would help solve the critical mass issues that have kept IPv6 on the back burner for 20 years. -wilhelm -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Digging into Symbols
On 4/27/20 2:42 PM, Guido Stepken wrote: In most Lisp languages, you only can "append" to a list, never "prepend".: "Prepend", aka "add to the beginning" seems the natural (and non-destructive) operation of Lisp, e.g. (cons 9 (1 2 3)) -> (9 1 2 3) ..perhaps that is what you meant? -wilhelm -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Digging into Symbols
In most Lisp languages, you only can "append" to a list, never "prepend". Python, e.g., has such structures: https://www.geeksforgeeks.org/deque-in-python/ The "*d*ouble *e*nded *queue*". Appending, prepending, Python simply lets you do, what you want! ;-) Mighty, mighty stuff, highly efficient! Have fun! Am Montag, 27. April 2020 schrieb Wilhelm Fitzpatrick : > I've been digging down to really understand the symbol implementation in Picolisp, since symbols are used for so many purposes within the language. > > One surprising thing I learned last night is that (get ...) has a side effect! It moves the key that was accessed to the head of the symbol "tail". I assume this is a performance optimization to cause recently accessed properties to "bubble up" to the front of the list in case they are re-accessed soon. > > A few questions: > > 1. I understand why (cdr) doesn't function on a symbol (semantically it's not a pair) but I'm curious why (car) is allowed to work (returning the VAL)? > > 2. Is there anyway within the REPL to inspect the tail structure of the symbol directly? This is mostly from curiosity. > > 3. Again from curiosity, I'm wondering why the bytes of the name are seemingly stored "backwards"? I'm assuming this also provides some performance optimization. > > -wilhelm > > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >
Re: Digging into Symbols
Thanks for the insights, Alex! On 4/27/20 1:53 PM, Alexander Burger wrote: This means, a pointer to a cell points direcly to its CAR, while a pointer to a symbol points to its VAL. In both cases (car ...) or (val ...) are just a single pointer derefernces (memory fetches). Ah, so car and val are effectively synonyms, and it's easier to allow that then prevent :) 3. Again from curiosity, I'm wondering why the bytes of the name are seemingly stored "backwards"? I'm assuming this also provides some performance optimization. Correct. The first character(s) need to be accessed more prominently. Hmm... because checking the first byte/character is just a mask, rather than shift & mask? -wilhelm -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Stop using US controlled software stacks!!!
Seems, you haven't the slightest idea, what's going on in world: China is changing gears, decoupling from TCP/IP protocol. Means: USA becoming isolated. It's a 320 million people state, making just 5% of global population. https://cntechpost.com/2020/03/30/huawei-aims-to-reshape-internet-with-protocol-called-new-ip/ China, in fact, is double as big as Europe and the US together. Apart from that, not only half of USA is bankrupt, with Corona now it's ⅔. Means: Germany also is saying 'goodbye' to USA, US technology, US protocols, US standards ... 'Show me the code' ... what code? I don't publish on M$ owned Github or M$ owned NPM and i will never do. Not a single US owned server will be allowed to carry a singe bit of my code ... Do i want to get into jail for nothing like Meng Wanzhou? No evidence, no proof. Or Assange, Guantanamo prisoners? See 'Military Commissions Act'. Means: Everything now gets isolated from US software/hardware implementations. There are even NSA Backdoors implemented in hardware, e.g. Broadcom Wifi silicon. All Open Source repositories (Github, NPM, Anaconda, NuGet) now are poisined by NSA backdoors!!! Seems, most of you guys haven't yet understood, what USA is aiming at: Total control of all software, hardware, communication on the world. Sorry, but simply don't care your little provocation. Either you agree with US strategies or you do down under! I've already warned Alex not to use US software stacks (LLVM) for Picolisp .. but he simply doesn't listen. Picolisp, for me, now is dead, burnt. I have to reimplement it now, because plenty of my code uses Picolisp. As i've already mentioned: Picolisp is a genius strike, carries plenty of pretty usable ideas in it. Well, using Picolisp, with mighty LLVM (420 Mbytes compressed bloat, backdoor injections by NSA everywhere, no security review possible) will be the last Picolisp for me. Pil21 is a NO-GO! Finished, for all times. You must know, how your friends are, Alex doesn't. Have fun! Am Montag, 27. April 2020 schrieb Danilo Kordic : > Guido Stepken: >> [...] > > ""Talk is cheap, show me the code."" -- Linus Torvalds > > -- > UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe > >
Re: Digging into Symbols
The "move-to-front" heuristic is equivalent to the LRU caching policy. The "move-up-by-one" heuristic converges to LFU (least frequently used) caching policy. Perhaps LFU is what you really want? BTW, "move-up-by-one" has a side-effect on every invocation, as does "move-to-front". However, you can do "move-up-by-one" only every 1/N times, and still converge to LFU. At 12:55 PM 4/27/2020, Wilhelm Fitzpatrick wrote: >I've been digging down to really understand the symbol implementation in >Picolisp, since symbols are used for so many purposes within the language. > >One surprising thing I learned last night is that (get ...) has a side effect! >It moves the key that was accessed to the head of the symbol "tail". I assume >this is a performance optimization to cause recently accessed properties to >"bubble up" to the front of the list in case they are re-accessed soon. > >A few questions: > >1. I understand why (cdr) doesn't function on a symbol (semantically it's not >a pair) but I'm curious why (car) is allowed to work (returning the VAL)? > >2. Is there anyway within the REPL to inspect the tail structure of the symbol >directly? This is mostly from curiosity. > >3. Again from curiosity, I'm wondering why the bytes of the name are seemingly >stored "backwards"? I'm assuming this also provides some performance >optimization. > >-wilhelm > >-- >UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Digging into Symbols
Hi Wilhelm, > that (get ...) has a side effect! It moves the > key that was accessed to the head of the > symbol "tail". I assume this is a performance > optimization to cause recently accessed > properties to "bubble up" to the front of the > list in case they are re-accessed soon. Yes, exactly. > 1. I understand why (cdr) doesn't function on > a symbol (semantically it's not a pair) but > I'm curious why (car) is allowed to work > (returning the VAL)? This is a result of the pointer structure of PicoLisp. As you may know (from e.g. doc64/structures), a cell is | V +-+-+ | CAR | CDR | +-+-+ while a symbol is | V +-+-+ | | VAL | +--+--+-+ This means, a pointer to a cell points direcly to its CAR, while a pointer to a symbol points to its VAL. In both cases (car ...) or (val ...) are just a single pointer derefernces (memory fetches). > 2. Is there anyway within the REPL to inspect > the tail structure of the symbol directly? It is in fact possible, with some tricky pointer arithmetics: : (put 'A 'a 1) -> 1 : (put 'A 'b 2) -> 2 : (val (adr (abs (adr 'A -> ((2 . b) (1 . a) . 65) > 3. Again from curiosity, I'm wondering why the > bytes of the name are seemingly stored > "backwards"? I'm assuming this also provides > some performance optimization. Correct. The first character(s) need to be accessed more prominently. ☺/ A!ex -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Re: Stop using US controlled software stacks!!!
Gudo Stepken: > [...] ""Talk is cheap, show me the code."" -- Linus Torvald -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
Digging into Symbols
I've been digging down to really understand the symbol implementation in Picolisp, since symbols are used for so many purposes within the language. One surprising thing I learned last night is that (get ...) has a side effect! It moves the key that was accessed to the head of the symbol "tail". I assume this is a performance optimization to cause recently accessed properties to "bubble up" to the front of the list in case they are re-accessed soon. A few questions: 1. I understand why (cdr) doesn't function on a symbol (semantically it's not a pair) but I'm curious why (car) is allowed to work (returning the VAL)? 2. Is there anyway within the REPL to inspect the tail structure of the symbol directly? This is mostly from curiosity. 3. Again from curiosity, I'm wondering why the bytes of the name are seemingly stored "backwards"? I'm assuming this also provides some performance optimization. -wilhelm -- UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe
