January 2020 - Pharo-dev - lists.pharo.org

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

by Sven Van Caekenberghe

> On 20 Jan 2020, at 17:39, HilaireFernandes <hilaire(a)drgeo.eu> wrote: > > It is indeed about *receiveDataInto:fromHost:port:* I am talking about. > > Its *fromHost* parameter is not of the same nature as the *toHost* parameter > in the message *sendUDPData:toHost:port: * > In the former it is expected a ByteArray to work, in the later a > SocketAdress. I don't see any indication in the code to prove your statement "Socket>>#sendUDPData:toHost:port: is assuming hostAddress to be a SocketAddress". Like I said, all primitives take host addresses to be a byte array (of which SocketAddress is a subclass). > *About the context. > *This school year I am doing basic Pharo programming with Dr.Geo (12 and 13 > years old). I wrote a school book[1] for that. But It is a bit tedious to > teach and not enough appealing. It may just be my fault or the format of the > book. For the next semester, I will explore alternative format, in more > independent teaching unit. > > For the longer term, I want to explore alternative way of teaching Pharo, > more appealing. Something more in the kids interest area. > > Do you know Minetest, it is a free implementation of Minecraft? It comes > with a server software and client instances communicating with the server > with a dedicated UDP protocol. In the past, we use it in an architecture > project in connexion with math. > > Written with Pharo, I envision a Minetest client using the UPD protocol to > interact with a server. This Pharo written client will be used as a > programming environment to control the kid avatar in the Minetest 3D world, > like a BotsInc of 3D. The Pharo client will not render the view, it will be > done by the usual Minetest client. > > For example, a kid could code the behaviour of his avatar to build a tower > with a Minetest DSL: > > ../.. > 100 timesRepeat: [ > avatar goUp > 4 timesRepeat: [ > 10 timesRepeat: [avatar dropBrick; moveForward]. > avatar turnLeft] ] > > > There are some extensions in Minetest client (Mod in Minetest terminology) > to do some basic programming but it is not as interesting as could be Pharo > programming with a dedicated DSL[3]. > > I speculate it could be pretty cool and it should meet a lot of success > among kids. Plus provide good teaching interest and more Pharo awareness. > > Hilaire > > [1] > https://launchpad.net/drgeo/trunk/19.09/+download/programmer-avec-drgeo.pdf > [2] http://www.minetest.net > [3] > https://forum.minetest.net/viewtopic.php?f=14&p=365620&sid=5d825763b9cb5579… 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. 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). If you then put hostAddress first in: Socket>>#receiveDataInto: aStringOrByteArray fromHost: hostAddress port: portNumber "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 | datagram := self receiveUDPDataInto: aStringOrByteArray. (hostAddress = (datagram at: 2) and: [ (datagram at: 3) = portNumber ]) ifTrue: [ ^ datagram at: 1 ] ifFalse: [ ^0 ] ] repeat it should work. Sven

Jan. 21, 2020

Processor>>activeProcess is wrong when a process is stepped by a forked process

by Thomas Dupriez

Hello Some time ago, I've stumbled upon a challenging bug in pharo. I tried some things, but this bug still eludes me. Maybe someone here has an idea? The bug is that the value of `Processor activeProcess` is wrong inside a process being stepped by a forked process. In other words, let's say process D is the (frozen) process I am debugging, and its code is to store the active process into some variable with `p := Processor activeProcess`: - If I step process D normally (with `D step`), then p is correct and worth process D - If I fork to create a process F that steps process D, then p is incorrect and worth process F You will find below the code of the two tests I am using to show the bug, as well as a condensed version of my findings so far. If you have any idea or lead as to where this bug could come from, I would be very grateful. Thomas Dupriez ----- Here is the code of the failing test, where process F steps process D: ``` /testActiveProcessInProcessSteppedInForkedProcess// //| s p D done |// //Â Â Â s := Semaphore new. done := false.// //Â Â Â "Create debugged process"// //Â Â Â D := [p := Processor activeProcess. done := true] newProcess name: 'D'; yourself.// //Â Â Â "Until the execution of the debugged process is over, create a forked process to step it"// //Â Â Â [done]// //Â Â Â Â Â Â whileFalse: [ // //Â Â Â Â Â Â Â Â Â [debuggedProcess step. s signal] forkNamed: 'F'.// //Â Â Â Â Â Â Â Â Â s wait.// //Â Â Â Â Â Â ].// //Â Â Â self assert: D identicalTo: p/ ``` And here is the passing test, where we step process D directly: ``` /testActiveProcessInProcessDirectlyStepped// //| s p D done |// //Â Â Â s := Semaphore new. done := false.// //Â Â Â "Create debugged process"// //Â Â Â D := [p := Processor activeProcess. done := true] newProcess name: 'D'; yourself.// //Â Â Â "Until the execution of the debugged process is over, step it directly"// //Â Â Â [done]// //Â Â Â Â Â Â whileFalse: [ // //Â Â Â Â Â Â Â Â Â debuggedProcess step.// //Â Â Â Â Â Â ].// //Â Â Â self assert: D identicalTo: p/ ``` ----- Here are my findings so far: The call chain of Process>>step is: - Process>>step - which calls Process>>evaluate:onBehalfOf: - which calls BlockClosure>>ensure: - which calls BlockClosure>>valueNoContextSwitch 1) Replacing the call to BlockClosure>>valueNoContextSwitch with a call to BlockClosure>>value does not affect the results of the test 2) Since #valueNoContextSwitch is a primitive, it cannot be instrumented easily. I instrumented right before and after it gets called in the code of BlockClosure>>ensure to check the value of active process. No wrong value there, so the problem appears inside the execution of #valueNoContextSwitch, and it disappears before this method call returns. 3) The block being evaluated by #valueNoContextSwitch contains a call to Context>>step, which ultimately calls InstructionStream>>interpretNextV3PlusClosureInstructionFor: (the method that read what the next bytecode is and applies it to the execution it is stepping. I instrumented this method to log the name of the active process, and the context being stepped during the execution of both tests. The log show a difference between the passing and failing test: - Passing test: the active process is D for a long time, then 'Test execution watch dog" for a bit, and finally, it is "Morphic UI Process". So everything looks in order: the active process is D until the test ends and the UI process takes control back - Failing test: The logged active process alternates between F and D, and looks like this: (I put some F D patterns in bold for readability) *F D* F D *F D*.....*F D* F F D F F *F D* F D *F D*...*F D* D D D D r M M M M... "M" is the morphic UI Process, "r" is a seemingly random process whose name is "1006977792" in the log. I also logged the ast nodes being stepped, but I don't really know how to exploit it. 4) I did some experiments by tweaking the tests and changing which process creates D, which process steps F...and had surprising results: 4-1) Original failing test a In the original failing test, the test process creates the debugged process and a fork, and the fork steps the debugged process (blue arrow). This test fails. 4-2) Original passing test a In the original passing test, the test process creates the debugged process and steps it. This test passes. 4-3) Forked process creates AND steps the debugged process a If the forked process is the one to create the debugged process, the test passes! 4-4) /Forked process creates the debugged process, and TestProcess steps it/ a So maybe the test passes whenever the debugged process is a descendant of the process stepping it? No, 4-5) shows that it is not necessary. 4-5) /A forked process creates the debugged process. Another forked process steps the debugged process /a

Jan. 21, 2020

[Pharo 9.0] Build #15: saferOmbuFileAccess

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

There is a new Pharo build available! The status of the build #15 was: SUCCESS. The Pull Request #5532 was integrated: "saferOmbuFileAccess" Pull request url: https://github.com/pharo-project/pharo/pull/5532 Issue Url: https://github.com/pharo-project/pharo/issues/saferOmbuFileAccess Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 21, 2020

[ANN] Pharo TechTalk Jan 23

by Marcus Denker

A regular chat about Pharo. Happens on Discord. â¢ When 23 Jan 2020 â¢ 5:00 PM - 6:00 PM (UTC+01:00) Topic: Contributing to Iceberg (Git support) https://association.pharo.org/event-3697009

Jan. 21, 2020

[Pharo 9.0] Build #14: SUCCESS

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

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

Jan. 21, 2020

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo 8.0 Released!

by Norbert Hartl

Great work and many thanks to all that supported!! Norbert > Am 20.01.2020 um 19:01 schrieb ducasse <stepharo(a)netcourrier.com>: > > I would like to also thanks all the consortium members and the association members so their continuous > support. In addition we would like to thank SchmidtPro and Lifeware for the contracts we sign to improve Pharo. > Pharo 80 and Pharo 90 will strongly benefit from this effort. > > S. > >> On 20 Jan 2020, at 14:23, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> Dear World and dynamic language lovers: >> The time has come for Pharo 8.0 <https://pharo.org/>! >> Pharo is a pure object-oriented programming language and a powerful environment, focused on simplicity and immediate feedback. >> >> Here are the key highlights of this release: >> >> The 64-bit version has become the recommended version for Windows as it was for Unix and OSX. >> Iceberg, the git client for Pharo, reached its version 1.6.5 with several improvements and bugfixes. >> Calypso, Pharoâs system browser has new and better refactoring integrations and AST-based suggestions for class definitions. >> The unified foreign function interface (UnifiedFFI) has been improved with more support for literal objects, better type coercions, and more documentation. >> Several speed improvements in code searches and compilation. >> >> In addition, this version includes several previews of new tools such as the Spec2 GUI framework with native widget integration and the new DrTests test analysis tool and opens the door for the upcoming headless VMs for servers and non-blocking FFI. >> These are just the more prominent highlights, but the details are just as important. We have closed a massive amount of issues: 2805 issues! >> A comprehensive changelog can be found at https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo80Change… <https://github.com/pharo-project/pharo-changelogs/blob/master/Pharo60Change…>). >> While the technical improvements are significant, still the most impressive fact is that the new code that got in the main Pharo 8.0 image was contributed by more than 100 people. >> Pharo is more than code. It is an exciting project involving energetic people. We thank all the contributors to this release: >> Serge Stinckwich, Myroslava Romaniuk, Hilaire Fernandes, Alexandre Bergel, David Bajger, Sean DeNigris, Theodore Moen, Dayne Guerra Calle, Juraj Kubelka, Max Leske, Santiago Jose Dandois, Alistair Grant, Sabine Mana, Chia Yu, Stephan Eggermont, Milton Mamani, Pavel Krivanek, Ben Coman, Marcus Denker, Pierre Misse, Christophe Demarey, Allex Oliveira, Andreina Cota, Theo Rogliano, ClÃ©ment Dutriez, Quentin Ducasse, Cyril Ferlicot, Cameron Bierwagen, Marek Niepieklo, Clotilde Toullec, Esteban Lorenzano, Vincent Blondeau, Danil Osipchuk, Eiichiro Ito, Noury Bouraqadi, Oleksandr Zaytsev, Jason Riggs, Alain Plantec, Kasper Osterbye, Leonardo Cecchi, Chi Huynh, Santiago Bragagnolo, Antonio Pierro, Pablo Tesone, Tim Mackinnon, Wesley Duerksen, Wilfred Hughes, John Brant, Evelyn Cusi Lopez, Manuel Leuenberger, Thomas Dupriez, Norbert Hartl, Torsten Bergmann, Gabriel Omar Cotelli, Carlo Teixeira, Guille Polito, Torsten Bergman, Damien Pollet, Holger Hans Peter Freyther, Julio Ripoll, Carolina Hernandez Phillips, Julien Delplanque, Hugo Lasnier, James Foster, Will Hensel, Erik Stel, Sven Van Caekenberghe, MartÃn Dias, Tomohiro Oda, Konrad Hinsen, SeÌbastien Roccaserra, StÃ©phane Ducasse, Denis Kudriashov, Ellis Harris, Steven Costiou >> (If you contributed with Pharo 8.0 development in any way and we missed your name, please send us a mail and we will add you). >> Enjoy! >> The Pharo Team >> Try Pharo: http://pharo.org/download <https://pharo.org/download> >> Learn Pharo: http://pharo.org/documentation <https://pharo.org/documentation> >> >> If you cannot see this, follow this link: http://pharo.org/news/pharo8.0-released <http://pharo.org/news/pharo8.0-released>

Jan. 21, 2020

[Mm10s] 2020-01-20

by ducasse

Last week - concurrent programming booklet - coded an interpreter for the new version of ObjVlisp called PicoCore. - reviewing work of Esteban Villalobos on improving rules - renaming rules and learning the hard way that we should have a protocol to unload classes (like in VW). - resuming fluid class definition parser - code reviews for P8 - better ProgramNodeVisitor (more and nicer hooks) -> Pharo 90 Forthcoming - finish concurrent programming booklet - working on fluid definition parser - look at live typing with hernan wilkinson - start to play with Spec20 - want to be a guinea pig for the new debugger

Jan. 20, 2020

Re: [Pharo-dev] [Mm10s] 2010-01-20

by ducasse

super cool list!!! Keep pushing Pablo. And this Mm10s is super cool because we always underestimate work of others. > On 20 Jan 2020, at 11:47, tesonep(a)gmail.com wrote: > > ### Last week: > > - Fix Issue #5434: Settings > - Fix Issue #5474: Logging messages with Metacello > - Fix Issue #5481: Metacello-logs-now-prints-lots-of-new-lines > - [VM] Example of branding VM and signed image in OSX / Win32 > - [VM] Improving the Documentation of the PharoVM repository. > - [Doc] Pass on the uFFI booklet (Chapters 1 & 2) > - Traits Paper > - Deadlock in Idle (Windows) > - [Pharo8] Buffer error in Sources. Check a problem with large > installations and the changes files > - [VM] Documenting GC, participating in the GC code dojo. > - [VM] Deadlock in Idle (Unix) (MMap location) > - [VM] Uploading Latest VM for Pharo 7/8/9 > - [Pharo8] Fixing broken tests in Enlumineur > - [Pharo8] Integrating a preview of Enlumineur (not available by default) > - [Iceberg] New release of Iceberg (v1.6.5): > - Speed improvements for loading bigger packages > - Local directory relative repositories > - Fixes in the Edit project dialog > - Adding default values to system settings. > - Adding Generic git repository in Metacello. > - [Release] Prepare release notes > - [Release] Prepare release mail > - [Release] Organise issues that will enter in P8. > - [FFI] Check FFI changes by Guille > - Add Pharo9 to SmalltalkCI > > ### This week (idea....): > > - [VM] Fixing Tests in Idle > - [Doc] Adding type Table to uFFI booklet > - [Doc] Pass on VM booklet > - [VM] SDL Plugin for Idle > - [VM] Documenting GC, participating in the GC code dojo. > - [VM] Improving Speed of TFFI > - [VM] Writing tests for JIT generation > - [Doc] Techtalk Iceberg > - FOSDEM preparation > > > -- > Pablo Tesone. > tesonep(a)gmail.com >

Jan. 20, 2020

Re: [Pharo-dev] printing Symbol

by ducasse

In fact I did it because this is irregular in the sense that binary selector should not printed with # while the keywords based symbol should. (RBScanner on: '(RBScanner on: 'Object < #MyObject classVariables: { #A. #B }; package: #MyPackage' readStream) contents collect: #value readStream) contents collect: #value >>> #('Object' #< #MyObject 'classVariables:' ${ #A $. #B $} $; 'package:' #MyPackage) and back should be 'Object < #MyObject classVariables: { #A. #B }; package: #MyPackage' > On 20 Jan 2020, at 16:22, ducasse <stepharo(a)netcourrier.com> wrote: > > Hi sven > > I think that I will have to hack my own, I was just surprised that we do not have a nice way back > from tokens back to code. (not talking about quote inside strings). > > > String streamContents: [ :s | > #('self' 'classVariables:' ${ #A $. #B $}) > do: [ :each | s print: each ] > separatedBy: [ s space ]]. > > '''self'' ''classVariables:'' ${ #A $. #B $}â > > S. > > > > >> On 20 Jan 2020, at 10:45, Sven Van Caekenberghe <sven(a)stfx.eu <mailto:sven@stfx.eu>> wrote: >> >> #foo printString. >> '#foo' >> >> String streamContents: [ :out | out print: #foo ]. >> '#foo' >> >> String streamContents: [ :out | out << #foo ]. >> 'foo' >> >> I would not use #storeOn: directly, I would consider the fact that String>>#printOn: uses it an implementation detail, and a confusing one at that. >> >>> On 20 Jan 2020, at 03:54, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: >>> >>> >>> >>>> On Jan 19, 2020, at 1:50 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> wrote: >>>> >>>> ï»¿ >>>> The idea that is that I would like to be able to >>>> >>>> text -> tokens -> text >>>> >>>> For text -> tokens >>>> >>>> (RBScanner on: 'self classVariables: { #A . #B }' readStream) >>>> contents collect: #value >>>> >>>> >>>> I wrote a little method that takes the result of the RBScanner and recreate the text >>>> But I cannot get this method to work. >>>> Iâm puzzled because the symbols are eaten. >>>> >>>> >>>> expressionStringFrom: aLine >>>> >>>> "self new >>>> expressionStringFrom: #('self' 'classVariables:' ${ #A $. #B $}) >>>> >>> >>>> 'self classVariables: { A . B }' >>>> " >>>> ^ String streamContents: [ :s | >>>> aLine >>>> do: [ :each | s << each ] >>>> separatedBy: [ s space ]] >>>> >>>> I tried with print:, printOn:, but I failed. >>>> >>>> Any idea? >>> >>> With Symbols one needs to use storeOn: >>> >>>> >>>> S. >>>> >>>> >>>> >>>> >>>> -------------------------------------------- >>>> StÃ©phane Ducasse >>>> http://stephane.ducasse.free.fr <http://stephane.ducasse.free.fr/> / http://www.pharo.org <http://www.pharo.org/> >>>> 03 59 35 87 52 >>>> Assistant: Julie Jonas >>>> FAX 03 59 57 78 50 >>>> TEL 03 59 35 86 16 >>>> S. Ducasse - Inria >>>> 40, avenue Halley, >>>> Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza >>>> Villeneuve d'Ascq 59650 >>>> France >

Jan. 20, 2020

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo 8.0 Released!

by Sven Van Caekenberghe

> On 20 Jan 2020, at 19:01, ducasse <stepharo(a)netcourrier.com> wrote: > > I would like to also thanks all the consortium members and the association members so their continuous > support. In addition we would like to thank SchmidtPro and Lifeware for the contracts we sign to improve Pharo. > Pharo 80 and Pharo 90 will strongly benefit from this effort. +10

Jan. 20, 2020