- Pharo-dev - lists.pharo.org

[ANN] New Headless VM (Still Alpha, but getting better)

by tesonep＠gmail.com

A new version of the headless VM is available. It can be downloaded from: https://files.pharo.org/vm/pharo-spur64-headless/win/PharoVM-8.3.0-b612fd5f… https://files.pharo.org/vm/pharo-spur64-headless/linux/PharoVM-8.3.0-b612fd… https://files.pharo.org/vm/pharo-spur64-headless/mac/PharoVM-8.3.0-b612fd5-… Or more easily using ZeroConf: With the image $ wget -O - get.pharo.org/64/90+vmHeadlessLatest | bash Without $ wget -O - get.pharo.org/64/vmHeadlessLatest90 | bash This new version has a series of bugfixes and the following features: - Update TFFI to v1.2.0: Allowing better marshaling and callbacks from outside threads. - Update README.md - Add instructions on how to create a vmmaker image. - Fixing UnixOSProcessPlugin - Redefinition of squeakFileOffset - Generating include files as an artifact - Adding a configurable strategy for reading / writing the image - Building using Musl Libc - A cleaner implementation of the print to stdout and file. - OSX File Dialog - OSX icon customization - OSX customization for apps. - Adding build on GitHub actions I will like to thank all the contributors specially Guille, Esteban, Ronnie. And also, Feenk and Schmidt that they are using it, reporting issues and contributing. Just a friendly reminder, if you want to contribute, you are always welcome!! https://github.com/pharo-project/opensmalltalk-vm Cheers, Pablo -- Pablo Tesone. tesonep(a)gmail.com

Jan. 28, 2020

Re: [Pharo-dev] [Mm10s] 2020-01-27

by Esteban Lorenzano

Oops, I forget the attach :) > On 27 Jan 2020, at 10:01, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > ### Last week > > * Release Pharo 8.0 > * [UFFI] See a problem in TFFI + Gtk3 backend caused by a change made to allow String econdings. > * [objcbridge] I made the bridge compatible with the latest version of TFFI > * [spec2] prepare a status document (I will attach it to this mail) > * [spec2] table/list/trees: default sort in string columns work. > * [Spec2-doc] add good comments to SpApplication > * [big images] review usages of SystemNavigation (and similars) in the image, looking to centralise its behaviour (so we can plan strategies). > * [big images] I got a functional calypso that uses notebook instead tabmanager. Still a lot of bugs to fix to make it functional (but it looks promising). > * [Morphic] I fixed some errors on SpNotebookMorph: is was not informing correctly the last page when a page changed event happened. > * Some branch clean up on pharo site > > ### This week > > * Work on speed up of big images (finish migration to notebook morph, start looking improvements on senders/implementors) > * Work on idle vm

Jan. 27, 2020

[Mm10s] 2020-01-27

by tesonep＠gmail.com

### Last week: - [Diffussion] Preparing Material for FOSDEM - [Doc] Adding type Table to uFFI booklet - [Pharo9] Running Bootstrap and tests in 64 bits - [Spotter] Add a setting to limit the number of results in Spotter - [Doc] Techtalk Iceberg - [VM] Documenting GC, participating in the GC code dojo. - [Large Images] Making Battle Plan with Esteban - [Large Images] 5562-Executing-All-Instances-in-the-startup-affects-loading-times - [Callbacks] Helping Schmidt to use TFFI Callbacks - [Callbacks] Detection of a deadlock when calling callbacks from a different thread while the VM is running. - [Pharo9] Fixing #5571 - Color settings should have default values ### This week (starting 2020-01-27): - [VM] Fixing Tests in Idle - [VM] Documenting GC, participating in the GC code dojo. - [VM] SDL Plugin for Idle - [VM] Improving Speed of TFFI - [VM] REPL example (?) - [VM] Writing tests for JIT generation - [Diffusion] FOSDEM preparation: material, trip organization, presentations - [Callbacks] Fixing Deadlock when a callback is executed from a different thread. - [Doc] Pass on VM booklet: Callback chapter / Preface - [LargeImages] Working on improving the speed and responsiveness of large images. -- Pablo Tesone. tesonep(a)gmail.com

Jan. 27, 2020

[Mm10s] 2020-01-27

by Esteban Lorenzano

### Last week * Release Pharo 8.0 * [UFFI] See a problem in TFFI + Gtk3 backend caused by a change made to allow String econdings. * [objcbridge] I made the bridge compatible with the latest version of TFFI * [spec2] prepare a status document (I will attach it to this mail) * [spec2] table/list/trees: default sort in string columns work. * [Spec2-doc] add good comments to SpApplication * [big images] review usages of SystemNavigation (and similars) in the image, looking to centralise its behaviour (so we can plan strategies). * [big images] I got a functional calypso that uses notebook instead tabmanager. Still a lot of bugs to fix to make it functional (but it looks promising). * [Morphic] I fixed some errors on SpNotebookMorph: is was not informing correctly the last page when a page changed event happened. * Some branch clean up on pharo site ### This week * Work on speed up of big images (finish migration to notebook morph, start looking improvements on senders/implementors) * Work on idle vm

Jan. 27, 2020

Re: [Pharo-dev] Wrong behavior of receiveDataInto:fromHost:port:

by David T. Lewis

On Sun, Jan 26, 2020 at 04:04:38PM +0300, Danil Osipchuk wrote: > in 2011 it was changed by 'ul' (I don't know whom the initials belong to) 'ul' is Levente Uzonyi (leves at caesar.elte.hu)

Jan. 26, 2020

Re: [Pharo-dev] Wrong behavior of receiveDataInto:fromHost:port:

by Danil Osipchuk

A bit of archeology. I could not find message sends quickly in https://github.com/NikolaySuslov/croquet-squeak and in 5.2 squeak image. Code by Johh MacIntosh of 2000 in squeak 5.2 is below, for the primitiveOnlySupportsOneSemaphore=true it relies on #setPeer:port which in turn does a linux syscall to connect(2) restricting socket to send/receive only to/from a single peer. in 2011 it was changed by 'ul' (I don't know whom the initials belong to) setPeer:port was dropped and this is how it stays since then both in squeak and pharo - purely image side logic to filter incoming datagrams. = JMM = receiveDataInto: aStringOrByteArray fromHost: hostAddress port: portNumber | datagram | "Receive a UDP packet from the given hostAddress/portNumber, storing the data in the given buffer, and return the number of bytes received. Note the given buffer may be only partially filled by the received data." primitiveOnlySupportsOneSemaphore ifTrue: [self setPeer: hostAddress port: portNumber. ^self receiveDataInto: aStringOrByteArray]. [true] whileTrue: [datagram := self receiveUDPDataInto: aStringOrByteArray. ((datagram at: 2) = hostAddress and: [(datagram at: 3) = portNumber]) ifTrue: [^datagram at: 1] ifFalse: [^0]] = ul = receiveDataInto: aStringOrByteArray fromHost: hostAddress port: portNumber | datagram | "Receive a UDP packet from the given hostAddress/portNumber, storing the data in the given buffer, and return the number of bytes received. Note the given buffer may be only partially filled by the received data." [ datagram := self receiveUDPDataInto: aStringOrByteArray. ((datagram at: 2) = hostAddress and: [(datagram at: 3) = portNumber]) ifTrue: [^datagram at: 1] ifFalse: [^0]] repeat Ð²Ñ, 26 ÑÐ½Ð². 2020 Ð³. Ð² 13:14, Danil Osipchuk <danil.osipchuk(a)gmail.com>: > As soon as you start listening on udp port every host having connectivity > will be able to send you a datagram which will hit a smalltalk handler. It > is a concern both from performance and security pov. You may be willing to > implement your own protocol suit on top of udp to have a tcp like endpoint > pairing and session managment, but without buffering/windowing and reliable > transmission to meet realtime requirements of gaming etc. For that you will > need this. > Probably it was used by multiuser collaboration project croquet > > https://en.m.wikipedia.org/wiki/Croquet_Proje > Regards > Danil > > Ð²Ñ, 26 ÑÐ½Ð². 2020 Ð³., 12:08 Sven Van Caekenberghe <sven(a)stfx.eu>: > >> >> >> > On 26 Jan 2020, at 09:42, HilaireFernandes <hilaire(a)drgeo.eu> wrote: >> > >> > Sven Van Caekenberghe wrote >> >> Sounds nice, and indeed a (more) fun way to teach programming. >> >> >> >> But I still fail to see why you have to filter incoming UDP packets on >> >> their origin address. >> > >> > If third party software on the workstation are connected to other >> network >> > services, don't you want to filter out? Or am I missing something? >> >> I think so: you listen on an UDP socket on a specific port (and >> optionally bound to a specific network interface on your machine), then you >> get only datagrams directed to you - this happens at the OS level. >> >> A (at host:port) sends a datagram to B (at host:port), to reply, B looks >> at the datagram to figure out the sender's info and replies. >> >> You can study the example UDPSocketEchoTest to see how this works. >> >> HTH, >> >> Sven >> >> >> >>

Jan. 26, 2020

Re: [Pharo-dev] Wrong behavior of receiveDataInto:fromHost:port:

by Danil Osipchuk

As soon as you start listening on udp port every host having connectivity will be able to send you a datagram which will hit a smalltalk handler. It is a concern both from performance and security pov. You may be willing to implement your own protocol suit on top of udp to have a tcp like endpoint pairing and session managment, but without buffering/windowing and reliable transmission to meet realtime requirements of gaming etc. For that you will need this. Probably it was used by multiuser collaboration project croquet https://en.m.wikipedia.org/wiki/Croquet_Proje Regards Danil Ð²Ñ, 26 ÑÐ½Ð². 2020 Ð³., 12:08 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > On 26 Jan 2020, at 09:42, HilaireFernandes <hilaire(a)drgeo.eu> wrote: > > > > Sven Van Caekenberghe wrote > >> Sounds nice, and indeed a (more) fun way to teach programming. > >> > >> But I still fail to see why you have to filter incoming UDP packets on > >> their origin address. > > > > If third party software on the workstation are connected to other network > > services, don't you want to filter out? Or am I missing something? > > I think so: you listen on an UDP socket on a specific port (and optionally > bound to a specific network interface on your machine), then you get only > datagrams directed to you - this happens at the OS level. > > A (at host:port) sends a datagram to B (at host:port), to reply, B looks > at the datagram to figure out the sender's info and replies. > > You can study the example UDPSocketEchoTest to see how this works. > > HTH, > > Sven > > > >

Jan. 26, 2020

Re: [Pharo-dev] Wrong behavior of receiveDataInto:fromHost:port:

by Sven Van Caekenberghe

> On 26 Jan 2020, at 09:42, HilaireFernandes <hilaire(a)drgeo.eu> wrote: > > Sven Van Caekenberghe wrote >> Sounds nice, and indeed a (more) fun way to teach programming. >> >> But I still fail to see why you have to filter incoming UDP packets on >> their origin address. > > If third party software on the workstation are connected to other network > services, don't you want to filter out? Or am I missing something? I think so: you listen on an UDP socket on a specific port (and optionally bound to a specific network interface on your machine), then you get only datagrams directed to you - this happens at the OS level. A (at host:port) sends a datagram to B (at host:port), to reply, B looks at the datagram to figure out the sender's info and replies. You can study the example UDPSocketEchoTest to see how this works. HTH, Sven

Jan. 26, 2020

Re: [Pharo-dev] Wrong behavior of receiveDataInto:fromHost:port:

by HilaireFernandes

Hi Sven, Sven Van Caekenberghe wrote > Sounds nice, and indeed a (more) fun way to teach programming. > > But I still fail to see why you have to filter incoming UDP packets on > their origin address. If third party software on the workstation are connected to other network services, don't you want to filter out? Or am I missing something? Sven Van Caekenberghe wrote > I do agree that using ByteArray and SocketAddress interchanging fails in > some cases, even though one is a subclass of the other, because #= fails, > due to the class check. > > I can't see an easy way to fix this (as #= is defined in > SequenceableCollection). One solution might be to add #species ByteArray > to SocketAddress, but it is hard to see the implications of that. > > Another option might be to add: > > SocketAddress>>#= anObject > ^ self == anObject or: [ self hasEqualElements: anObject ] > > This way, #= would work when the SocketAddress is the receiver (but not > the other way around which is ugly). Yes, not to be symmetric is a bit a problem, likely not a good addition to Pharo. I will see how it goes on my exploration of this topic. Thanks Hilaire ----- http://drgeo.eu -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Jan. 26, 2020

[Pharo 9.0] Build #27: SUCCESS

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #27 was: SUCCESS. Could not extract further issue information from commit message: Merge branch 'Pharo9.0' of github.com:pharo-project/pharo into Pharo9.0 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 25, 2020