October 2015 - Pharo-dev - lists.pharo.org

binary serialization

by Robert Withers

Does Pharo have stream classes to binary de/serialize an object, such that the protocol accepts an object as an argument and converts it to a byteArray? -- thanks, Robert

Oct. 13, 2015

Re: [Pharo-dev] Slack?

by Dimitris Chloupis

extremely, nothing comes remotely close. Pretty much every open source project has at least one channel in freenode.net, quakenet is very popular with gamers . #python has around 2000 people online at all times, #clojure 700 , #java 466 , #c++ 1000, #emacs 1000, there is even irc channels for computets back from the 80s like my first computer Amstrad CPC 6128 at #cpc etc Blender which the program I use the most has around 5 channels, Blender also is a bit special in that all the development effort is coordinated via irc meetings usually every Sunday where all main devs are required to attend , moderated by the project leader , and make decisions on how the project should proceed, which features should go in and when the releases should come out. The project leader then publishes the meeting notes on the website which is a summary of the irc chat. There are other projects that follow similar approach to their development too like mypaint and Gimp. On Tue, Oct 13, 2015 at 4:30 AM Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Just wondering. Is IRC still popular? > > Alexandre > > > > On Oct 6, 2015, at 1:03 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> > wrote: > > > > Quite frankly, the reason why IRC is so extremely popular, is because it > does its job very well and has some very nice clients. I am active at > #Pharo because I use several IRC channels, #Blender , #C++ , #Opengl , > #MACOS , #unrealengine , #emacs , #blendercoders and #blenderpython. So the > incredible power of IRC is not its features, but its community. > > > > I dont have an issue giving a slack a try but I see no reason to. > > > > On Tue, Oct 6, 2015 at 6:05 PM Esteban A. Maringolo < > emaringolo(a)gmail.com> wrote: > > 2015-10-06 11:41 GMT-03:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > > >>>> I think it would be better than the IRC alternative, no matter how > > >>>> good your IRC client is. > > >>> > > >>> why? because is new? #irc is around since a lot and it has work fine > for many groups of different sizes. > > > > > > Ey! I know IRC and used it since BitchX and then mIRC! > > > > > > But it's not because it's new, it's because is prettier, in provides > > > nice integrations with other services (GitHub, CI, you name it), file > > > previews. > > > > I just found it has a Gateway so you can use your existing XMPP or IRC > > client to connect to it. > > > > So no need to stop using your beloved IRC client :) > > > > I'm trying to set it up. > > > > Regards! > > > > -- > > Esteban. > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Oct. 13, 2015

Re: [Pharo-dev] [Vm-dev] Re: issue with large file path on windows

by Thierry Goubier

Hi Eliot, I believe everytime this comes up, it is not an issue of filetree making files too long for the filesystem, it is an issue of Pharo not being able to read or write a valid file for the filesystem. It is easy to "fix" filetree to workaround bugs in FilePlugin on Windows, but I'm not sure it's the right way to solve the problem ;) Simply because someone will hit it when reading a random, valid file one day. Thierry Le 13/10/2015 01:01, Eliot Miranda a Ã©crit : > Hi Nicolai, > > I have to say that the problem lies with the git integration. The > length of Smalltalk selectors is effectively unlimited and the language > encourages Kong descriptive names. Many (most?) unixes have a > limitation of 256 characters in any path element and a PATH_MAX that may > be as little as 1024. So the current architecture is, for me, way too > close to implementation limits. IMO a far better design would be to use > protocol names, all methods per protocol, eg Object.accessing or two > files per class (instance & class side) with methods ordered by > selector. Either of those, but especially the last, should give good > diff results in git but be well away from the implementation limit. The > one method per file, selector as file name approach is asking for trouble. > > _,,,^..^,,,_ (phone) > > On Oct 12, 2015, at 3:04 PM, Nicolai Hess <nicolaihess(a)web.de > <mailto:nicolaihess@web.de>> wrote: > >> >> >> 2015-09-15 9:19 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de >> <mailto:nicolaihess@web.de>>: >> >> >> >> 2015-09-14 23:10 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com >> <mailto:eliot.miranda@gmail.com>>: >> >> >> Thanks Nicolai, that's great! I'll merge in your changes. >> Which files do I need to look at? >> >> >> I changed (removed my code, added Marcels) >> platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c >> platforms/win32/vm/sqWin32.h >> platforms/win32/vm/sqWin32Directory.c >> >> I added (should be the same as in squeak vm repository) >> platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c >> >> >> But my changes only about that code that already is in squeaks >> repository. >> >> If we want to merge some of the pharo-vm code into squeaks branch, we >> first need to wrap that code with some #ifdefs >> >> (For the win32 file/directory stuff, this would be code in >> platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c >> platforms/win32/vm/sqWin32.h >> platforms/win32/vm/sqWin32Directory.c >> and >> platforms/Cross/plugins/FilePlugin/FilePlugin.h) >> >> Maybe Estaban should look at this, and tell which path he would >> follow to >> merge those changes. >> >> >> OK, these changes are now in pharos vm repository, .... >> >> >> but I just found another issue with long paths, squeak and pharo: >> >> This is a path from one github repository based package >> >> u:\pharo_images\images\Pharo 5.0 >> (beta)-50376\github-cache\mtaborda\aconcagua\master\mtaborda-aconcagua-4d0a14f\repository\Aconcagua-Core.package\NotProportionalDerivedUnit.class\instance\initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st >> >> Yes, pathlength is 282! But I think the problem is not the overall >> path name, but the length of the filename. >> >> On squeak, you can open and browse the parent directory in a FileList >> and even show the contents of the contained files. >> On Pharo, this does not work, because Pharos FileList uses a different >> method for accessing the file attributes. >> (the difference is, we call dir_EntryLookup, whereas (most) of Squeaks >> FileList methods just call dir_Lookup). >> >> But there are some methods in Squeak that call dir_EntryLookup and >> those are failing too. >> >> For example: >> >> "Creating a Stream and reading the contents works" >> (FileStream fileNamed:'u:\pharo_images\images\Pharo 5.0 >> (beta)-50376\github-cache\mtaborda\aconcagua\master\mtaborda-aconcagua-4d0a14f\repository\Aconcagua-Core.package\NotProportionalDerivedUnit.class\instance\initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st') >> contents. >> >> "Creating a Stream and accessing the directory entry does not work" >> (FileStream fileNamed:'u:\pharo_images\images\Pharo 5.0 >> (beta)-50376\github-cache\mtaborda\aconcagua\master\mtaborda-aconcagua-4d0a14f\repository\Aconcagua-Core.package\NotProportionalDerivedUnit.class\instance\initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st') >> directoryEntry >> " -> Error: file not in directory: >> initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st" >> >> >> nicolai >> >>

Oct. 13, 2015

updated Cryptography

by Robert Withers

I am attaching the .mcz as I am unsure where to publish it. I fixed a few issues (hex is lowercase and inputs to SecureRandom) and all tests pass green in the latest Pharo 5.0. Is there a good place for this to live? -- thanks, Robert

Oct. 13, 2015

Re: [Pharo-dev] really

by Robert Withers

That's good advice, Alexandre. thanks, Robert On 10/12/2015 09:27 PM, Alexandre Bergel wrote: > Define a small model, pick some examples and write unit tests. > > Alexandre > > >> On Oct 12, 2015, at 8:33 PM, Robert Withers <robert.w.withers(a)gmail.com> wrote: >> >> This is what I want to build. What do you suggest I do? >> >> Thanks, >> >> Robert >> <RabbitPhone+Business+Plan.pdf> >

Oct. 13, 2015

Re: [Pharo-dev] Slack?

by Alexandre Bergel

Just wondering. Is IRC still popular? Alexandre > On Oct 6, 2015, at 1:03 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > Quite frankly, the reason why IRC is so extremely popular, is because it does its job very well and has some very nice clients. I am active at #Pharo because I use several IRC channels, #Blender , #C++ , #Opengl , #MACOS , #unrealengine , #emacs , #blendercoders and #blenderpython. So the incredible power of IRC is not its features, but its community. > > I dont have an issue giving a slack a try but I see no reason to. > > On Tue, Oct 6, 2015 at 6:05 PM Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2015-10-06 11:41 GMT-03:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > >>>> I think it would be better than the IRC alternative, no matter how > >>>> good your IRC client is. > >>> > >>> why? because is new? #irc is around since a lot and it has work fine for many groups of different sizes. > > > > Ey! I know IRC and used it since BitchX and then mIRC! > > > > But it's not because it's new, it's because is prettier, in provides > > nice integrations with other services (GitHub, CI, you name it), file > > previews. > > I just found it has a Gateway so you can use your existing XMPP or IRC > client to connect to it. > > So no need to stop using your beloved IRC client :) > > I'm trying to set it up. > > Regards! > > -- > Esteban. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 13, 2015

Re: [Pharo-dev] really

by Alexandre Bergel

Define a small model, pick some examples and write unit tests. Alexandre > On Oct 12, 2015, at 8:33 PM, Robert Withers <robert.w.withers(a)gmail.com> wrote: > > This is what I want to build. What do you suggest I do? > > Thanks, > > Robert > <RabbitPhone+Business+Plan.pdf> -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 13, 2015

really

by Robert Withers

This is what I want to build. What do you suggest I do? Thanks, Robert

Oct. 12, 2015

Alien and FFI in Pharo

by Robert Withers

I want to get NIO sockets working using FFI, which I understand means Alien. I can't seem to load Alien from the Catalog. What do you suggest I do? -- thanks, Robert

Oct. 12, 2015

Re: [Pharo-dev] [Vm-dev] Re: issue with large file path on windows

by Eliot Miranda

Hi Nicolai, I have to say that the problem lies with the git integration. The length of Smalltalk selectors is effectively unlimited and the language encourages Kong descriptive names. Many (most?) unixes have a limitation of 256 characters in any path element and a PATH_MAX that may be as little as 1024. So the current architecture is, for me, way too close to implementation limits. IMO a far better design would be to use protocol names, all methods per protocol, eg Object.accessing or two files per class (instance & class side) with methods ordered by selector. Either of those, but especially the last, should give good diff results in git but be well away from the implementation limit. The one method per file, selector as file name approach is asking for trouble. _,,,^..^,,,_ (phone) > On Oct 12, 2015, at 3:04 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2015-09-15 9:19 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: >> >> >> 2015-09-14 23:10 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>> >>> Thanks Nicolai, that's great! I'll merge in your changes. Which files do I need to look at? >> >> I changed (removed my code, added Marcels) >> platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c >> platforms/win32/vm/sqWin32.h >> platforms/win32/vm/sqWin32Directory.c >> >> I added (should be the same as in squeak vm repository) >> platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c >> >> >> But my changes only about that code that already is in squeaks repository. >> >> If we want to merge some of the pharo-vm code into squeaks branch, we >> first need to wrap that code with some #ifdefs >> >> (For the win32 file/directory stuff, this would be code in >> platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c >> platforms/win32/vm/sqWin32.h >> platforms/win32/vm/sqWin32Directory.c >> and >> platforms/Cross/plugins/FilePlugin/FilePlugin.h) >> >> Maybe Estaban should look at this, and tell which path he would follow to >> merge those changes. > > OK, these changes are now in pharos vm repository, .... > > > but I just found another issue with long paths, squeak and pharo: > > This is a path from one github repository based package > > u:\pharo_images\images\Pharo 5.0 (beta)-50376\github-cache\mtaborda\aconcagua\master\mtaborda-aconcagua-4d0a14f\repository\Aconcagua-Core.package\NotProportionalDerivedUnit.class\instance\initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st > > Yes, pathlength is 282! But I think the problem is not the overall path name, but the length of the filename. > > On squeak, you can open and browse the parent directory in a FileList and even show the contents of the contained files. > On Pharo, this does not work, because Pharos FileList uses a different method for accessing the file attributes. > (the difference is, we call dir_EntryLookup, whereas (most) of Squeaks FileList methods just call dir_Lookup). > > But there are some methods in Squeak that call dir_EntryLookup and those are failing too. > > For example: > > "Creating a Stream and reading the contents works" > (FileStream fileNamed:'u:\pharo_images\images\Pharo 5.0 (beta)-50376\github-cache\mtaborda\aconcagua\master\mtaborda-aconcagua-4d0a14f\repository\Aconcagua-Core.package\NotProportionalDerivedUnit.class\instance\initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st') contents. > > "Creating a Stream and accessing the directory entry does not work" > (FileStream fileNamed:'u:\pharo_images\images\Pharo 5.0 (beta)-50376\github-cache\mtaborda\aconcagua\master\mtaborda-aconcagua-4d0a14f\repository\Aconcagua-Core.package\NotProportionalDerivedUnit.class\instance\initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st') directoryEntry > " -> Error: file not in directory: initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st" > > > nicolai > >

Oct. 12, 2015

building the pharo-vm failed

by Robert Withers

I am trying to build the vm and I got an error during make, listed at the bottom is one item that had error, but there were many conflicting types errors. I started with the latest bz2 from here: http://files.pharo.org/vm/src/vm-unix-sources/blessed/. I setup my tool environment (Ubuntu). The README.md says do a make in the platforms dir but that failed. Recommended to me was the git repo: https://github.com/pharo-project/pharo-vm/blob/master/README.md So, I ran: git clone --depth=1 https://github.com/pharo-project/pharo-vm.git cd build ./build.sh It pulled the image, generated sources then started to make the results when I got this error. What should I do now? -- thanks, Robert /home/robert/.local/share/Pharo/pharo-vm/src/vm/cogit.c:3418:1: error: conflicting types for âconcretizeMoveAwRâ concretizeMoveAwR(AbstractInstruction * self_in_concretizeMoveAwR) ^ /home/robert/.local/share/Pharo/pharo-vm/src/vm/cogit.c:457:14: note: previous declaration of âconcretizeMoveAwRâ was here static sqInt concretizeMoveAwR(AbstractInstruction * self_in_concretizeMoveAwR) NoDbgRegParms; ^

Oct. 12, 2015

Re: [Pharo-dev] [Vm-dev] Re: issue with large file path on windows

by Nicolai Hess

2015-09-15 9:19 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > > > 2015-09-14 23:10 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> >> Thanks Nicolai, that's great! I'll merge in your changes. Which files >> do I need to look at? >> > > I changed (removed my code, added Marcels) > platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c > platforms/win32/vm/sqWin32.h > platforms/win32/vm/sqWin32Directory.c > > I added (should be the same as in squeak vm repository) > platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c > > > But my changes only about that code that already is in squeaks repository. > > If we want to merge some of the pharo-vm code into squeaks branch, we > first need to wrap that code with some #ifdefs > > (For the win32 file/directory stuff, this would be code in > platforms/win32/plugins/FilePlugin/sqWin32FilePrims.c > platforms/win32/vm/sqWin32.h > platforms/win32/vm/sqWin32Directory.c > and > platforms/Cross/plugins/FilePlugin/FilePlugin.h) > > Maybe Estaban should look at this, and tell which path he would follow to > merge those changes. > > OK, these changes are now in pharos vm repository, .... but I just found another issue with long paths, squeak and pharo: This is a path from one github repository based package u:\pharo_images\images\Pharo 5.0 (beta)-50376\github-cache\mtaborda\aconcagua\master\mtaborda-aconcagua-4d0a14f\repository\Aconcagua-Core.package\NotProportionalDerivedUnit.class\instance\initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st Yes, pathlength is 282! But I think the problem is not the overall path name, but the length of the filename. On squeak, you can open and browse the parent directory in a FileList and even show the contents of the contained files. On Pharo, this does not work, because Pharos FileList uses a different method for accessing the file attributes. (the difference is, we call dir_EntryLookup, whereas (most) of Squeaks FileList methods just call dir_Lookup). But there are some methods in Squeak that call dir_EntryLookup and those are failing too. For example: "Creating a Stream and reading the contents works" (FileStream fileNamed:'u:\pharo_images\images\Pharo 5.0 (beta)-50376\github-cache\mtaborda\aconcagua\master\mtaborda-aconcagua-4d0a14f\repository\Aconcagua-Core.package\NotProportionalDerivedUnit.class\instance\initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st') contents. "Creating a Stream and accessing the directory entry does not work" (FileStream fileNamed:'u:\pharo_images\images\Pharo 5.0 (beta)-50376\github-cache\mtaborda\aconcagua\master\mtaborda-aconcagua-4d0a14f\repository\Aconcagua-Core.package\NotProportionalDerivedUnit.class\instance\initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st') directoryEntry " -> Error: file not in directory: initializeBaseUnit.conversionBlock.reciprocalConversionBlock.nameForOne.nameForMany.sign..st" nicolai

Oct. 12, 2015

[ANN] New SqueakSSL binaries (v0.2.0b) for Linux

by Tobias Pape

Hi all, I've created a new version of the SqueakSSL binaries: https://github.com/itsmeront/squeakssl/releases/tag/v0.2.0b Only changes: â¢ Linked the Linux binary statically against LibreSSL 2.2.3 (was 2.2.1) â¢ Produce SqueakSSL and so.SqueakSSL with the correct sonames â¢ Explicitly link the Linux binaries with librt (was omitted by default) The OSX and Windows versions stayed. The actual C code did not change. Best regards -Tobias

Oct. 12, 2015

Re: [Pharo-dev] Storing System Settings using STON

by Yuriy Tymchuk

Also you can save and load all settings using the buttons in top right corner > On 12 Oct 2015, at 21:45, Juraj Kubelka <juraj.kubelka(a)gmail.com> wrote: > > Hi, > > we have a slice that introduce new storage solution for System Settings. See: https://pharo.fogbugz.com/f/cases/16681/Storing-System-Settings-using-STON <https://pharo.fogbugz.com/f/cases/16681/Storing-System-Settings-using-STON> > > You can load it using: > > Gofer it > smalltalkhubUser: 'Pharo' project: 'Pharo50Inbox'; > package: 'SLICE-Issue-16681-Storing-System-Settings-using-STON'; > load. > > When you open the Setting Browser, you can see that every setting has new items in context menu: > > <Screen Shot 2015-10-08 at 11.49.10.png> > > Thanks for reviewing it. > Cheers, > Juraj

Oct. 12, 2015

Re: [Pharo-dev] Pharo needs you

by Aliaksei Syrel

Thanks for pointing out such usecase, Stef! This is indeed important On Oct 12, 2015 9:16 PM, "stepharo" <stepharo(a)free.fr> wrote: > Hi guys > > We are working like mad on the mooc and I'm stuck because to produce cool > videos I cannot get the correct fonts > because the widgets are not using font size :( > Look at the attachment. > This is how one day we pay our sloppiness. > So I will reduce the font size but it sucks. > Stef >

Oct. 12, 2015

Re: [Pharo-dev] Slack?

by Esteban A. Maringolo

We're already 31 registered users, with an average of 20% online! Please promote it, maybe we could reach 100 by the end of the year. Best regards! Esteban A. Maringolo 2015-10-08 15:51 GMT-03:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: > If anybody still wants to join, and because Slack requires an > invitation to join, please go to http://slack4pharo.trentosur.com and > type your email address so we can send you the invite! > > I'd like to get around 40 users aboard by the end of this month. > > Regards! > > > Esteban A. Maringolo > > > 2015-10-06 15:58 GMT-03:00 Esteban A. Maringolo <emaringolo(a)gmail.com>: >> 2015-10-06 15:12 GMT-03:00 stepharo <stepharo(a)free.fr>: >>> Not sure that yet another tool will help me to be more productive. >>> Don't count me in it. >> >> I don't think it aims at making somebody more productive, but instead >> to gather people with similar interests and avoid querying the mailing >> list for trivial things. >> >> Let's see if it works, if not, closing it is instantaneous. >> >> >> Esteban A. Maringolo

Oct. 12, 2015

Storing System Settings using STON

by Juraj Kubelka

Hi, we have a slice that introduce new storage solution for System Settings. See: https://pharo.fogbugz.com/f/cases/16681/Storing-System-Settings-using-STON You can load it using: Gofer it smalltalkhubUser: 'Pharo' project: 'Pharo50Inbox'; package: 'SLICE-Issue-16681-Storing-System-Settings-using-STON'; load. When you open the Setting Browser, you can see that every setting has new items in context menu: Thanks for reviewing it. Cheers, Juraj

Oct. 12, 2015

Re: [Pharo-dev] About Magritte Seaside

by Dale Henrichs

On 10/12/2015 02:58 AM, Christophe Demarey wrote: > > Le 11 oct. 2015 Ã 22:32, Dale Henrichs a Ã©crit : > > With our approach, metadata lies in the package for the current > version and it is on the package repository when the version is > released. Platform-specific packages could have their own dependencies. > What will be possible is to create a new package (not a source code > package but a package that is used by a package manager, i.e. > metadata) to support a new platform and reusing existing code (by > pointing to the package source code). > Do you have an example to provide to me? > >> With all of that said, I really do love the idea of not having to >> support Metacello anymore:) So I would like to see you succeed with >> your effort! > > It will take time ... > I would really like to get feedbacks on Cargo because the knowledge > you got with Metacello is invaluable. > >>>> Perhaps at this point in time, I'd like to read some code. Then I >>>> can skip reading the paper and get a feel for how hard it will be >>>> to port to GemStone:) >>> I do not know where christophe save his code but it is be public. >> I may not have time to read a paper ... but I would have time to read >> code:) > > http://smalltalkhub.com/#!/~demarey/CargoPackageManager > <http://smalltalkhub.com/#%21/%7Edemarey/CargoPackageManager> > While I think we might be trying to solve different problems ... I will take a close look at the code in CargoPackageMananger ... too bad, the code isn't on github, because it would be much easier for me to read, comment and contribute:) Dale

Oct. 12, 2015

Pharo needs you

by stepharo

Hi guys We are working like mad on the mooc and I'm stuck because to produce cool videos I cannot get the correct fonts because the widgets are not using font size :( Look at the attachment. This is how one day we pay our sloppiness. So I will reduce the font size but it sucks. Stef

Oct. 12, 2015

Re: [Pharo-dev] [Vm-dev] hello

by Eliot Miranda

Hi SebastiÃ¡n, and welcome! Forgive me for not replying earlier. On Mon, Oct 12, 2015 at 4:54 AM, SebastiÃ¡n Krynski <skrynski(a)gmail.com> wrote: > > Hello my name is SebastiÃ¡n Krynski from Buenos Aires, Argentina. > Just writing to let you know that I'm starting to work on adding an atomic > swap operator in Pharo , guaranteed not to be interrupted by the VM. The > operator will be used this way: > > a :=: b > > meaning 'swap variable a with variable b'. > In order to do this I will be modifying the VM and the Compiler . > > I'm working under the direction of INRIA and Gabriela ArÃ©valo. > Give my regards to Gabriela! One thing is to consider multiple approaches. My friend Maurice Rabb (in the cc line) did a concurrent VM for a smalltalk-like language a few years ago now and he used something more akin to compare-and-swap. e.g. var ?= value := expr would set var to expire if it held the value var and answer true, otherwise it would not change the value of var and answer false. Talk also to Igor Stasenko (also in the cc line) who has thought a lot about this and has written a prototype image-level scheduler based on (IIRC) a couple of different atomic operators. Another thing to think about is goals. Making it convenient to implement lock-free data structures such as a lock-free thread-safe dictionary would be very good. Make sure you look at Cliff Click's work, e.g. at Azul such as A Lock-Free, Wait-Free Hash Table <https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CB4QFj…>. Google cliff click azul lock-free data structures <https://www.google.com/search?client=safari&rls=en&q=cliff+click+azul+lock-…> . Finally, decide where you want to discuss this. My preference is for you to at least include vm-dev, since this is definitely to do with the byte code set and the VM. But the data structure piece and the use is more generally useful. So I see no problem including vm-dev, pharos-dev and the general purpose squeak list. The more the merrier. A couple of questions: How long will your work with Gabriela last? Is this a master's project or a PhD or...? Good luck! _,,,^..^,,,_ best, Eliot

Oct. 12, 2015

Re: [Pharo-dev] Problems with a large block

by Eliot Miranda

Thanks Henry. Your approach seems much more rational. For example,e, branches are to the start of a byte code sequence, and return addresses are to the start of the byte code following the send. There is no case I can think of when the last byte of a byte code is an important ordinal, not even in cannotReturn: or illegalBytecode:. On Mon, Oct 12, 2015 at 7:37 AM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > > On 12 Oct 2015, at 3:43 , Henrik Johansen <henrik.s.johansen(a)veloxit.no> > wrote: > > > On 10 Oct 2015, at 10:05 , Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2015-10-08 23:45 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> Hi Nicolai, >> >> On Thu, Oct 8, 2015 at 2:27 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >>> Hello Eliot, and thanks for your time. >>> >>> >>> In our (pharo) implementation for sourceNodeForPC, we start at the >>> AST-Node of >>> the compiled method, get the IR (IntermediateRepresentation) and scan >>> this sequence of IRNodes >>> until we finally find that one, that maps to the bytecode of the closure >>> creation code (this should be a IRPushClosureCopy). >>> The problem is now, we don't find (always) the right IRNode, and it >>> depens on the number of local temps, if this is > 3 we don't hit the right >>> one. >>> >> >> That's very strange. Can you construct a synthetic example of two simple >> blocks, one with three temps and and one with four temps and show me the >> difference in the byte code? >> > > > [ :x | | a b c | a:=b:=c:=x ] "calling #sourceNode gives a > RBBlockNode - ok" > Bytecode > 13 <8F 01 00 0B> closureNumCopied: 0 numArgs: 1 bytes 17 to 27 > 17 <73> pushConstant: nil > 18 <73> pushConstant: nil > 19 <73> pushConstant: nil > 20 <10> pushTemp: 0 > 21 <81 43> storeIntoTemp: 3 > 23 <81 42> storeIntoTemp: 2 > 25 <81 41> storeIntoTemp: 1 > 27 <7D> blockReturn > 28 <7C> returnTop > > > [ :x | | a b c d | a:=b:=c:=d:=x ] "calling #sourceNode gives a > RBMethodNode - not ok" > Bytecode > 13 <8F 01 00 0E> closureNumCopied: 0 numArgs: 1 bytes 17 to 30 > 17 <73> pushConstant: nil > 18 <73> pushConstant: nil > 19 <73> pushConstant: nil > 20 <73> pushConstant: nil > 21 <10> pushTemp: 0 > 22 <81 44> storeIntoTemp: 4 > 24 <81 43> storeIntoTemp: 3 > 26 <81 42> storeIntoTemp: 2 > 28 <81 41> storeIntoTemp: 1 > 30 <7D> blockReturn > 31 <7C> returnTop > > As I wrote above, in Pharo, to get the sourceNode we try to find the push > closure bytecode from "startpc - 1" by traversing > the IR and try to get the IRNode with matching "bytecodeOffset". The > bytecodeOffsets for the above blocks: > > [ :x | | a b c | a:=b:=c:=x ] > "bytecodeOffset -> IR" > 19->pushClosureCopyCopiedValues: #() args: #(#x) > 28->returnTop > 20->pushTemp: #x > 22->storeTemp: #c > 24->storeTemp: #b > 26->storeTemp: #a > 27->blockReturnTop > > [ :x | | a b c d | a:=b:=c:=d:=x ] > "bytecodeOffset -> IR" > 20->pushClosureCopyCopiedValues: #() args: #(#x) > 31->returnTop > 21->pushTemp: #x > 23->storeTemp: #d > 25->storeTemp: #c > 27->storeTemp: #b > 29->storeTemp: #a > 30->blockReturnTop > > Both blocks don't have a bytecodeOffset matching the bytecode of the > pushclosure (13), but we start the search from "startpc - 1" (= 16) > and do a loop from 0 to -3 (because bytecodes can have a length of 1,2 or > 4) > For the first block, this works > bytecodeOffset 19 = 16 - (-3) > For the second block this does not work, somehow the bytecodeoffset value > depends on the number of local temps. And for the > second block this is one greater. > > > > >> And my interpretation was, the IRPushClosureCopy node has the wrong >>> "bytecode offset" (whatever this is). The bytecodeOffset value (somehow) >>> depends on the number of local temps, but maybe this is right (for >>> whatever this is used) and we are just using it wrong for in this situation. >>> >> >> So you need to ask Marcus how to interpret bytecodeOffset. The thing is, >> it should be simple. One has: >> >> BlockCreationBytecode >> any number of pushConstant: nil's (0 to N) >> first byte code in block >> last bytecode in block (always a blockReturnTop) >> >> and a block's startup is always that of the byte immediately following >> the BlockCreationBytecode. So if the byte code offset is somehow the span >> of the "any number of pushConstant: nil's (0 to N)" then there's a bug in >> the IR somewhere when the number of temps is > 3. But if that's not what >> it means then, well, I don't know what the problem is. >> >> > > For some reason, bytecodeOffset is the *last* byte associated with IR. > This makes little sense to me, the main use seems to be to get correct > offsets for different instructions in an IR sequence. > Since block IR includes temp initialization bytes, the offset is 5. > > Changing the code to record *starting* offset of an IRNode in IRSequence, > by: > mapBytesTo: instr > "Associate the current byte offset with instr. We fix this later to have > the correct offset, > see #bytecodes" > instrMap add: instr -> (bytes size + 1) > > and mapping bytes *before* visiting node in the IRTranslatorV2: > visitInstruction: instr > gen mapBytesTo: instr. > self visitNode: instr. > > and the same in visitPushClosureCopy: closure > closure copiedValues do: [:name | > gen mapBytesTo: closure. > gen pushTemp: (self currentScope indexForVarNamed: name). > ]. > --snip-- > > > Hupps, the pushing of copiedValues are not part of the closure bytecode, > so that needs to be > closure copiedValues do: [:name | > gen pushTemp: (self currentScope indexForVarNamed: name). > ]. > gen mapBytesTo: closure. > > Thanks testBlockAndContextSourceNode! > > After a recompile of the test methods in case of cached IR (and offsets) > (RPackageOrganizer default packageNamed: 'OpalCompiler-Tests') classes > do:#recompile > All (existing) tests are green with the attached change set (where > haltOnce's were removed too), at least in the almost-release version of > Pharo4 I tested in. > > Cheers, > Henry > > > > > > -- _,,,^..^,,,_ best, Eliot

Oct. 12, 2015

Re: [Pharo-dev] [ANN] Cupboard inspector for Teapot

by Attila Magyar

This is very nice thanks, and Cupboard is an awesome name. -- View this message in context: http://forum.world.st/ANN-Cupboard-inspector-for-Teapot-tp4855120p4855188.h… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Oct. 12, 2015

Re: [Pharo-dev] About Magritte Seaside

by Dale Henrichs

On 10/12/2015 02:58 AM, Christophe Demarey wrote: > > Le 11 oct. 2015 Ã 22:32, Dale Henrichs a Ã©crit : > >> When you talk about "virtual packages", I would say that a BaselineOf >> is pretty much a "virtual package" already. > > I don't think BaselineOf could be seen as a virtual package. > In package A, you tell that A depends on V. > In package B, you simply tell that B provides V. Many other packages > could also provide V. > Then, it is the solver's job to take the most relevant package > providing V. ah ... I had a different definition of "virtual package" in mind:) > >> When it comes to cross-platform support there are several factors >> that were built into Metacello from the very beginning: >> >> - it should be possible to USE a package on a different platform >> than it was >> originally written for without modifying the package itself > > +1 > TBH, it is not yet implement in Cargo because I have a dilemnia: once > you release a version, you should not edit it anymore. > On another hand, you would like to say that this package released and > validated on Pharo 4 is also valid for Pharo5. > A good compromise would be to be able to edit *only *some metadata of > a released package. This is another reason why I think that embedded package dependency is a bad idea .... who controls what meta data gets modified and how do you guarantee integrity. As I consider my response I think I am beginning to see where the difference in our thought processes lie ... For example my "virtual package" is defined as a specific commit in a git repository (or any other disk-based SCM) ... the version of the release is defined as the SHA of the commit, or a tag, or a branch name ... The components of this virtual package are one or more monticello packages and a BaselineOf.. One uses the virtual package by cloning the git repository to the local disk or by using a `github://` description ... I choose this approach, because in Smalltalk we typically deal with source code that has to be compiled into our working image ... I think that with your "virtual package", you are taking the approach where you are treating the Smalltalk source code as if it were a pre-compiled entity (like linux packages) and the dependencies between projects is more difficult to deal with because you have to worry about the compatibility exeutable binaries ... In the linux world these binary packages need their own dependency mechanisms independent of a development environment so indeed there are very different requirements involved here ... including the need to have dependency specifications independent of the dependency specifications used in the development environment ... If this is closer to the truth, then I will have to say that my primary concern today is for development time dependencies and the types of packages that you are talking about with the Cargo Package Manager are aimed at a completely different problem space altogether ... BTW, I will read your source code so that I can confirm my supposition ... Dale

Oct. 12, 2015

Re: [Pharo-dev] Relation between Garage PG and PGv2

by Esteban A. Maringolo

2015-10-12 14:05 GMT-03:00 Torsten Bergmann <astares(a)gmx.de>: > > Hi Esteban, > > we noticed the same "copy reuse" issue with NBSQlite. > > See this thread: > http://forum.world.st/Garage-and-SQLite-file-databases-general-project-stru… > > which ended up in a different discussion on URLs. I did not really understood > but had not time to look deeper and reproduce Guilles arguments clearly. Yeap, I remember seeing such discussion. But I got on it when it was a discussion about URLs, didn't see the part of the fork. But if it is the same with NBSQlite as it is with PostgresV2 then it's a waste of resources[1], as I suspected, it is not an "common API" for Database connectivity, but instead it is a fork of database drivers to work under a common API using inheritance rather than composition to reach the multi-driver approach. :-/ Regards, Esteban A. Maringolo [1]: It breaks rules #1, #3, #4, #13, #16 and #17 of the unix philosophy :) > Thanks > T. > > > Gesendet: Montag, 12. Oktober 2015 um 16:57 Uhr > Von: "Esteban A. Maringolo" <emaringolo(a)gmail.com> > An: "Pharo Developers" <pharo-dev(a)lists.pharo.org> > Betreff: [Pharo-dev] Relation between Garage PG and PGv2 > > Hi all, and Guille Polito in particular, > > I'm loading the Garage classes into Pharo 4, and I see the Garage-Postgres package "duplicates" the classes of the PostgresV2 package, but instead of using the PG prefix, it uses the GA prefix. This is in particular with the case of Garage-Postgres-Protocol package. > > Why is it so? > > Because even GAConnection>>#buildDefaultConnectionArgs (which is a replica of PGConnection) references PGConnectionArgs instead of GAConnectionArgs, which is the replica of the first. > > > QUESTION: Isn't Garage a "common API" for the *existing* drivers? (like a common wrapper), and if so it delegates the protocol handling to the real driver? In the PostgresV2 package in this case, to PG prefixed classes. > > Regards! > > > Esteban A. Maringolo >

Oct. 12, 2015

Re: [Pharo-dev] About Magritte Seaside

by Dale Henrichs

On 10/12/2015 02:20 AM, Christophe Demarey wrote: > Le 11 oct. 2015 Ã 18:42, Dale Henrichs a Ã©crit : > >> >> On 10/11/15 12:19 AM, stepharo wrote: >>> >>> Le 11/10/15 00:40, Dale Henrichs a Ã©crit : >>>> Christophe, >>>> >>>> I still don't have a lot of time to read the paper and try to understand what you are trying to accomplish, >>> you should read it. :) >>> We wrote it for that and it is not boring nor long. >> I scanned through it at the time and as I recall, I thought that the functionality described was already covered by git and BaselineOf ... but I did not read it in great detail and I did not (and still don't) have the time to compose a long-winded response:) >>>> but I am curious how you think "package dependencies" will play with git-based projects? >>>> >>>> In git-based repositories I don't think you have the same type of dependency issues that one might have with monticello repositories --- In a monticello repository you have a whole range of possible package versions to pick from, but in a git-based repository the range of package versions is fixed to those that are committed together so the packages that are meant to work together are committed together. >>> I think that this is only true for packages committed within the same repo. >>> Now between porjects published in different repo you have to express them. >>> I do not think that we all want to publish in the same repo and clone out everything. >> ... and inter-project dependencies is what a BaselineOf does .... which brings me back to the conclusion that I reached when I scanned the paper:) >>>> In the bootstrap scenario, you would only have one version per package to choose from, so the packages that are meant to work together are committed together .... >>>> >>>> I guess I don't know what you mean when you say: >>>>> we want to decouple a released version of a package from the working copy of the package version description (implies the creation of a package repository + a web interface on top of it to promote/search packages). >>>> Perhaps a description of the problem being solved would help me understand. >>> We want to be able to have a package market place where tools can grab dependencies without to load code >>> and can compute the set of packages that should be loaded. >>> >>> When a package is released into the market: then it externalise its metadata so that a crawler can automatically build >>> dependency graph and create specific distribution. >> Okay. This is a problem .... but it happens to be a problem that Metacello "can solve/does solve" - so there must be something else (a deeper problem?) that I don't quite understand. >> >> With that said, if you are planning to replace Metacello, then I am excited:) But I will repeat that I hope that you are considering cross platform issues ... >> >> Perhaps at this point in time, I'd like to read some code. Then I can skip reading the paper and get a feel for how hard it will be to port to GemStone:) > Well, the point is not to replace metacello but to go towards a per package metadata description allowing some flexibility with the introduction of virtual packages. Oh darn, you mean I have to continue to support Metacello:) > This will allow, in a first time, to set up a package repository and more important, a web site on top of it. In a second time, I also want to enable more flexibility in expressing dependencies constraints (eg. > 2.0, 3.*, etc.). To achieve that, you need a very performant dependency solver and I would like to reuse linux ones (it has be done for ocaml by example) through CUDF (check http://mancoosi.org/ There are a couple of different schemes for expressing "version ranges" in Metacello. Have you looked at them? By reuse, do you mean that you will reimplement the algorithms in Smalltalk or are you suggesting that depency resolution will only work on linux? From a practical perspective I am curious what problems will be solved by having "dependency constraints" expressed by anything more complicated than what I use for github: github://dalehenrich/tode:v0.0.?/repository Which translates to load the latest patch version of the tode project (where major.minor.patch) ... I know that in theory more complicated schemes are intersting, but that assumes that the developers assigning version numbers are actually adhering to a rational version numbering scheme and from a practical matter even the above pattern is risky business:) > > For now, I implemented a simple solver for static dependency constraints (=1.2). I checked Metacello implementation and it looked to me that approaches are a bit too far to be able to reuse the whole code. For sure, it is not as robust as Metacello is, because you enhanced it for years. > What I want now, is to experiment (let's name it) Cargo Package Manager to see if it fits the needs. Pharo bootstrap is the first use case. okay, so this is just in the experimental phases .... so for the time being I should be focussing my efforts on the minimal Metacello approach rather than get involved in the Cargo Package Manager? Dale

Oct. 12, 2015

Re: [Pharo-dev] Relation between Garage PG and PGv2

by Torsten Bergmann

Hi Esteban, we noticed the same "copy reuse" issue with NBSQlite. See this thread: http://forum.world.st/Garage-and-SQLite-file-databases-general-project-stru… which ended up in a different discussion on URLs. I did not really understood but had not time to look deeper and reproduce Guilles arguments clearly.Â Thanks T. Â Gesendet:Â Montag, 12. Oktober 2015 um 16:57 Uhr Von:Â "Esteban A. Maringolo" <emaringolo(a)gmail.com> An:Â "Pharo Developers" <pharo-dev(a)lists.pharo.org> Betreff:Â [Pharo-dev] Relation between Garage PG and PGv2 Hi all, and Guille Polito in particular, Â I'm loading the Garage classes into Pharo 4, and I see the Garage-Postgres package "duplicates" the classes of the PostgresV2 package, but instead of using the PG prefix, it uses the GA prefix. This is in particular with the case of Garage-Postgres-Protocol package. Â Why is it so?Â Â Because even GAConnection>>#buildDefaultConnectionArgs (which is a replica of PGConnection) references PGConnectionArgs instead ofÂ GAConnectionArgs, which is the replica of the first. Â QUESTION: Isn't Garage a "common API" for the *existing* drivers? (like a common wrapper), and if so it delegates the protocol handling to the real driver? In the PostgresV2 package in this case, to PG prefixed classes. Â Regards! Â Â Esteban A. Maringolo

Oct. 12, 2015

Re: [Pharo-dev] About Magritte Seaside

by Dale Henrichs

On 10/12/2015 01:42 AM, Christophe Demarey wrote: > Hi Dale, > > Le 11 oct. 2015 Ã 00:40, Dale Henrichs a Ã©crit : > >> Christophe, >> >> I still don't have a lot of time to read the paper and try to >> understand what you are trying to accomplish, but I am curious how >> you think "package dependencies" will play with git-based projects? > > Dependencies are not tied to a Version Control System (monticello, git > or whatever). Dependencies are a package concern. > With a released version, at the end, we need to fech source code from > a VCS (as we do not have a shared binary format): these steps are > already done by MC*Repository classes, including git. Yes but I am asking specifically how this link is specified ... in Metacello, you use repository descriptions to identify the source repository. I am curious how you specify these cross repository dependencies ... or do you even support cross-repository dependencies? > >> In git-based repositories I don't think you have the same type of >> dependency issues that one might have with monticello repositories >> --- In a monticello repository you have a whole range of possible >> package versions to pick from, but in a git-based repository the >> range of package versions is fixed to those that are committed >> together so the packages that are meant to work together are >> committed together. > > Git allows you to easily reference a set of packages working together. > It works fine for packages of the same repository but you get back the > problem since you deal with packages of other repositories. right and in Metacello the cross-repository specifications is handled by a project spec: spec baselineOf: 'Seaside' repository: 'github://SeasideSt/Seaside:v3.2.0/repository' In this case the git version is specified as part of the repository spec (v3.2.0 is a git tag) ... it gets back to how do you handle cross repository references? > >> In the bootstrap scenario, you would only have one version per >> package to choose from, so the packages that are meant to work >> together are committed together .... > > For the first step of the bootstrap, it will work but not for next > steps where we will split the Pharo image into different projects. and how are project dependencies handled? It seems that the project dependencies are intimately tied to package dependencies as often the project dependency itself comes from a specific set of packages and needs to be specified at the package level ... > >> I guess I don't know what you mean when you say: >>> we want to decouple a released version of a package from the working >>> copy of the package version description (implies the creation of a >>> package repository + a web interface on top of it to promote/search >>> packages). >> Perhaps a description of the problem being solved would help me >> understand. > > When you develop, you have a working copy of a package meta-data, > including dependencies. Actually, there are current dependencies of > the package. You could avoid to refer to specific versions and just > point to the package name as your working image should already have > packages loaded. (kind of configurationOf baseline) This is a BaselineOf in Metacello ... and does exactly what you talk about here ... > When you release a version (strong act), then you "freeze" the current > working version of the package meta-data and you publish it somewhere > (a package repository) so that it becomes available to others. This > metadata is not source cod, is easily accessible by tools and it > becomes easy to build a web site on top of this to search / promote > packages. > So, the problems I'm trying to solve there are: > > * do not be tied to a VCS and do not need to load code to "play" > with packages metadata > As I've mentioned in another message, there is no reason other than a lack of tools that the Metacello specifications (ConfigurationOf and BaselineOf) are not stored in XML/JSON/STON files ... I never liked the idea that code had to be loaded, but it was expedient at the time ... > > * offer a central place to easily find the package you need (for > example, java has http://central.sonatype.org/, php has > https://packagist.org/, etc.) > I am curious about your use of the term "package" here ... is this "package" as in Monticello package, or "package" as in a collection of packages and project dependencies ... or ConfigurationOf or BaselineOf? > > * do not mix preoccupations: I do not want to have metadata of all > released versions + working copy of a package at the same place > Have you looked at a BaselineOf? I also don't like the fact that ConfigurationOf has release and version information embedded in it ... but the ConfigurationOf was invented to plug the gap between what was available in the Monticello eco-system and what is available in a full-featured scm like git. The BaselineOf was invented because git was able to take care of all of version relationships and Metacello no longer needed all of that junk. If you look at a BaselineOf you will see that it is reduced to a single baseline method with package dependencies specified by name (the entire BaselineOf applies to all of the packages in a directory on disk managed by git or whatever) very simple very compact and very easy to maintain ... the only reason one touches a BaselineOf is to change a dependency.... So I think that for what you seem to need all that needs to be done is to define an XML/JSON/STON representation for the data in a BaselineOf ... a generator for a different format could easily be written and could take existing BaselineOf and spit out the data ... Dale

Oct. 12, 2015

Re: [Pharo-dev] About Magritte Seaside

by Dale Henrichs

On 10/11/2015 11:10 PM, stepharo wrote: > >> >> A BaselineOf has a single baseline method and only the "pure" >> dependencies amongst the packages and projects needs to be expressed >> ... and these dependency specs are about "as small" as you can get ... >>> > Yes but we want them per package. > We do not work on that since more than one year by accident. >>>>> >>>>> When a package is released into the market: then it externalise >>>>> its metadata so that a crawler can automatically build >>>>> dependency graph and create specific distribution. >>>> Okay. This is a problem .... but it happens to be a problem that >>>> Metacello "can solve/does solve" - so there must be something else >>>> (a deeper problem?) that I don't quite understand. >>> But you have to load the configuration and somehow execute it so >>> that it computes the dependencies and we do not want. >> Do you recall that I have been reminding folks that the >> specifications for ConfigurationOf and BaselineOf will someday become >> an XML file? ... I have taken great pains over the years to preserve >> this "expectation" ... Remember the choice to use classes was made as >> a bootstrap convenience to avoid having to create tools ... 6 years >> later and there is still a dearth of tools:) >> >> When you "execute" the code in a ConfigurationOf or BaselineOf, a >> completely separate data structure is constructed using a >> well-defined API and it is this "data structure" that does the real >> work ... it would be very easy to convert a BaselineOf into an >> XML/JSON/STON file without losing any information, unless you've have >> disregarding my warnings:) >> >> There is nothing in Metacello "project specifications" that _depends_ >> upon executing code ... > I know what I meant was use of pragmas, chaining pragma, loading all > the configuration information (different baselines....). > Yeah, I meant that too ... I believe that the entire Metacello specification (ConfigurationOf and BaselineOf) can be represented in an XML/JSON/STON file modulo all of the extra methods that folks have tacked onto the ConfigurationOf for conevenience... but I don't consider that extra stuff part of Metacello ... while chained pragmas, etc. can be represented in XML/JSON/STON files, the primary reason that they are present is to support the ConfigurationOf ... a BaselineOf is typically a single method and doesn't use all of that extra stuff ... >>>> With that said, if you are planning to replace Metacello, then I am >>>> excited:) But I will repeat that I hope that you are considering >>>> cross platform issues ... >>> Yes we do. First we wanted to make it work. Then we should have kind >>> of virtual packages that act as platforms or project level >> When you talk about "virtual packages", I would say that a BaselineOf >> is pretty much a "virtual package" already. >> >> When it comes to cross-platform support there are several factors >> that were built into Metacello from the very beginning: >> >> - it should be possible to USE a package on a different platform >> than it was >> originally written for without modifying the package itself >> - it should be possible to SUBSTITUTE a platform-specific package with >> another platform-specific package without modifying either of >> the packages >> - it should be possible to CHANGE the package dependencies based on >> platform-dependent requirements without modifying any of the >> packages >> >> The key here is that if one needs to change a package to use it on a >> different platform then you lose the ability to share source code. > > I see well the reason. :) > The last point is the most tricky one when we have per package > dependencies. But I will let christophe answers. It's the reason that I think per package dependencies (at least embedded in the package structure itself) is a bad idea ... it not only gets in the way of cross platform usage, but for the more complicated projects you end up having to touch a bunch of different files to make a "simple dependency change" not to mention having to edit different versions of the same package that may participate in different/conflicting dependency chains ... >> >> The BaselineOf satisfies these requirements, because the "project >> meta data" is separate from the package/source code and the >> BaselineOf itself is cross-platform. >> >> If you haven't thought about these issues from the very beginning, >> then it may not be easy to shoe-horn support in after the fact ... > > I will let christophe answer. >> >> With all of that said, I really do love the idea of not having to >> support Metacello anymore:) So I would like to see you succeed with >> your effort! > > Thanks. We will need help definitively. I have been looking at what would need to be done to "port Metacello" to the base GemStone product so that the GLASS/GSDevKit packages could be loaded "directly" into the system, as opposed to the current route, which has a fair amount complicated bootstrapping involved ... I would be using only BaselineOf so the it would not be necessary to port all of Metacello to the base GemStone product ... While I think that I can carve out a "minimal Metacello" it wouldn't be completely free of complication, since I have a commitment to keep the old Metacello functioning and I cannot afford to support two independent versions of Metacello ... If instead I worked with Christophe on this project (and it would meet my needs) then I would save myself a fair amount of work:) And part of that savings would be invested in building a Metacello-bridge to the new packages so that there would be a smooth transition ... > >>>> Perhaps at this point in time, I'd like to read some code. Then I >>>> can skip reading the paper and get a feel for how hard it will be >>>> to port to GemStone:) >>> I do not know where christophe save his code but it is be public. >> I may not have time to read a paper ... but I would have time to read >> code:) > > :) It's the same reason I don't read comments in the code .... when you read the code, you get to see what is actually being done as opposed to what the developer (or comment writer) wants you to think is being done:) Often there is a disparity between what the comment says and what the code does and in my experience the code always seems to win:) Dale

Oct. 12, 2015

[ANN] Pharo Sprint October 23

by marcus.denker＠inria.fr

We will organize a Pharo sprint / Moose dojo Friday, 23th October, starting at 10:00am. (Local Time Lille). It will be at the Inria Lille, Building B, third floor (RMoD offices). Remotely, you can join us on the official IRC channel #pharo on irc.freenode.net <http://irc.freenode.net/> server. During the sprint, we will try to synchronize local and remote Pharo sprinters. As the building is not open to the public, please contact us before if you plan to come.

Oct. 12, 2015

Re: [Pharo-dev] hello

by Thierry Goubier

2015-10-12 16:46 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > > > 2015-10-12 15:33 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: > >> >> On Mon, Oct 12, 2015 at 3:20 PM, Thierry Goubier < >> thierry.goubier(a)gmail.com> wrote: >> >>> Hi SebastiÃ n, >>> >>> 2015-10-12 13:53 GMT+02:00 SebastiÃ¡n Krynski <skrynski(a)gmail.com>: >>> >>>> Hello my name is SebastiÃ¡n Krynski from Buenos Aires, Argentina. >>>> Just writing to let you know that I'm starting to work on adding an >>>> atomic swap operator in Pharo , guaranteed not to be interrupted by the VM. >>>> The operator will be used this way: >>>> >>>> a :=: b >>>> >>>> meaning 'swap variable a with variable b'. >>>> >>> >>> Why a cryptic, special syntax? The compiler could inline an explicit >>> message send which would make the intent clear. >>> >> >> See previous discussions about <=> indeed. >> >>> >>> a atomicSwapWith: b. >>> >>> Well, anyway, the compiler has to do something special there. >>> >>> Could we have something like... >>> >>> [ | temp | >>> temp := a. >>> a := b. >>> b := a ] atomic >>> >>> ? Would a compiler be able to merge that in a swap instruction? And make >>> another type of processing for a different code inside the block? >>> >> >> We have Mutex>>critical: aBlock etc. >> >> Why not Atomic>>do: aBlock ? >> > > Honestly this block followed by atomic is very confusing IMO. That means > that the compiler has to raise an error if it did not succeed to compile > the block in a single cpu instruction, i.e., a single bytecode that > compiles to a single cpu instruction. For example: > [ | temp | > temp := a. > a := b. > b := a. > self foo ] atomic > has to raise a compilation error as the block cannot be compiled in a > single instruction. Overall very few instructions in specific order can be > compiled in a such a block. > Oh, Clement, compilers can do a lot more than that ;) This one would be easy to do, even if a bit ad-hoc (it's just a simple refactoring pattern to recognize, after all). Let me see... '[ | `x | `x := `y. `y := `z. `z := `x] atomic' RBParseTreeSearcher treeMatching: '[ | `x | `x := `y. `y := `z. `z := `x]' in: (RBParser parseExpression: '[ | temp | temp := a. a := b. b := temp ] atomic') Note that it fails on all the wrong variants you wrote, which leads me to spend more time if I got my pattern right :( But I was considering that it would be either an atomic swap (if the compiler recognize the sequence ... I usually see test_and_set as the primitive, and nowadays everybody saying transactional memory instructions are the way to go) or a critical if it can't be compiled as an atomic instruction (in short, same semantics? but different speeds... I think the trade-off is acceptable) > > Atomic>>#do: can work but the argument block needs to be compiled in a > single instruction so the bytecode compiler has to aware of the syntax > based on the selector anyway. For example, in: > anAtomic do: [ | temp | > temp := a. > a := b. > b := a ] > then the compiler has to compile the block specifically to have single > instruction, even if the call to anAtomic is done in the runtime. > Same as the atomic case above. Atomic should be a singleton; no need to create instances of Atomic, even conceptually. > > On the other hand a new special selector as #atomicSwapWith:, in a similar > way to #ifTrue:ifFalse:, is definitely doable and easy to implement. If you > think it's more readable then it's the way to go. It does not extend the > syntax so I think it can be done like that for the experiment as it is > simpler to implement. > I think this is an important point. Marcus, can something special like that be done via a compiler plugin or a MetaLink? This would be really convenient. Thierry > > > >> >> Would indeed be more readable than :=: >> >> Phil >> >>> >>> >>>> In order to do this I will be modifying the VM and the Compiler . >>>> >>>> Good luck. This is an important step. >>> >>> >>>> I'm working under the direction of INRIA and Gabriela ArÃ©valo. >>>> >>> >>> Welcome! >>> >>> Thierry >>> >> >> >

Oct. 12, 2015

Relation between Garage PG and PGv2

by Esteban A. Maringolo

Hi all, and Guille Polito in particular, I'm loading the Garage classes into Pharo 4, and I see the Garage-Postgres package "duplicates" the classes of the PostgresV2 package, but instead of using the PG prefix, it uses the GA prefix. This is in particular with the case of Garage-Postgres-Protocol package. Why is it so? Because even GAConnection>>#buildDefaultConnectionArgs (which is a replica of PGConnection) references PGConnectionArgs instead of GAConnectionArgs, which is the replica of the first. QUESTION: Isn't Garage a "common API" for the *existing* drivers? (like a common wrapper), and if so it delegates the protocol handling to the real driver? In the PostgresV2 package in this case, to PG prefixed classes. Regards! Esteban A. Maringolo

Oct. 12, 2015

Re: [Pharo-dev] Another pass on catalog web-site (Styling)

by Ben Coman

looks cool. thanks Esteban. cheers -ben On Mon, Oct 12, 2015 at 6:25 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > I made another pass on catalog web-site. This time I just enhanced a bit the stylingâ¦ still a lot to do but is looking better and better: http://catalog.pharo.org (you might need a force refresh) > > But in fact, this announce is just an excuse to remember you to enhance your configurations with catalog information as described here: http://catalog.pharo.org/catalog/note-for-developers > Also, if your configuration is proved to work on Pharo 3, 4 or 5, please copy your configuration into that repository, to avoid it to appear under âUnstableâ tag. > > The Catalog is just as good as the information it provides: there is A LOT of very good packages no one will ever notice (like Aconcagua, for example), that does not provide *any* information and therefore they will never be used :( > > PLEASE PLEASE PLEASE UPDATE YOUR CONFIGURATIONS! > > cheers, > Esteban

Oct. 12, 2015

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/50382 Home: https://github.com/pharo-project/pharo-core

Oct. 12, 2015

[pharo-project/pharo-core] 9ef1c3: 50382

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 9ef1c30b540a7418d150dede106373b6f4ef3111 https://github.com/pharo-project/pharo-core/commit/9ef1c30b540a7418d150dede… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-10-12 (Mon, 12 Oct 2015) Changed paths: M ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/symbolic versions/stable_.st A ConfigurationOfRubric.package/ConfigurationOfRubric.class/instance/versions/version20_.st A Deprecated50.package/MultistateLabelMorph.class/README.md A Deprecated50.package/MultistateLabelMorph.class/definition.st A Deprecated50.package/MultistateLabelMorph.class/instance/accessing/colorMap.st A Deprecated50.package/MultistateLabelMorph.class/instance/accessing/colorMap_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/defaultColorMap.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/disabledColor.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/disabledColor_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/drawOn_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/initWithContents_font_emphasis_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/interactionState_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/mouseOverColor_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/normalColor_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/pressedColor_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/selectedColor_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/selectedDisabledColor_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/selectedMouseOverColor_.st A Deprecated50.package/MultistateLabelMorph.class/instance/as yet unclassified/selectedPressedColor_.st A Deprecated50.package/MultistateLabelMorph.class/instance/initialization/initialize.st M Komitter.package/Komitter.class/instance/announcement/mcPackageModified_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/README.md R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/definition.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/accessing/colorMap.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/accessing/colorMap_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/defaultColorMap.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/disabledColor.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/disabledColor_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/drawOn_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/initWithContents_font_emphasis_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/interactionState_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/mouseOverColor_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/normalColor_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/pressedColor_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/selectedColor_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/selectedDisabledColor_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/selectedMouseOverColor_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/as yet unclassified/selectedPressedColor_.st R Morphic-Widgets-Basic.package/MultistateLabelMorph.class/instance/initialization/initialize.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50381.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50382.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50381.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50382.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50382 16730 Should sync back Rubric https://pharo.fogbugz.com/f/cases/16730 16765 Typo https://pharo.fogbugz.com/f/cases/16765 16766 Deprecate unreferenced/unused MultistateLabelMorph https://pharo.fogbugz.com/f/cases/16766 http://files.pharo.org/image/50/50382.zip

Oct. 12, 2015

Re: [Pharo-dev] hello

by ClÃ©ment Bera

2015-10-12 15:33 GMT+02:00 phil(a)highoctane.be <phil(a)highoctane.be>: > > On Mon, Oct 12, 2015 at 3:20 PM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> Hi SebastiÃ n, >> >> 2015-10-12 13:53 GMT+02:00 SebastiÃ¡n Krynski <skrynski(a)gmail.com>: >> >>> Hello my name is SebastiÃ¡n Krynski from Buenos Aires, Argentina. >>> Just writing to let you know that I'm starting to work on adding an >>> atomic swap operator in Pharo , guaranteed not to be interrupted by the VM. >>> The operator will be used this way: >>> >>> a :=: b >>> >>> meaning 'swap variable a with variable b'. >>> >> >> Why a cryptic, special syntax? The compiler could inline an explicit >> message send which would make the intent clear. >> > > See previous discussions about <=> indeed. > >> >> a atomicSwapWith: b. >> >> Well, anyway, the compiler has to do something special there. >> >> Could we have something like... >> >> [ | temp | >> temp := a. >> a := b. >> b := a ] atomic >> >> ? Would a compiler be able to merge that in a swap instruction? And make >> another type of processing for a different code inside the block? >> > > We have Mutex>>critical: aBlock etc. > > Why not Atomic>>do: aBlock ? > Honestly this block followed by atomic is very confusing IMO. That means that the compiler has to raise an error if it did not succeed to compile the block in a single cpu instruction, i.e., a single bytecode that compiles to a single cpu instruction. For example: [ | temp | temp := a. a := b. b := a. self foo ] atomic has to raise a compilation error as the block cannot be compiled in a single instruction. Overall very few instructions in specific order can be compiled in a such a block. Atomic>>#do: can work but the argument block needs to be compiled in a single instruction so the bytecode compiler has to aware of the syntax based on the selector anyway. For example, in: anAtomic do: [ | temp | temp := a. a := b. b := a ] then the compiler has to compile the block specifically to have single instruction, even if the call to anAtomic is done in the runtime. On the other hand a new special selector as #atomicSwapWith:, in a similar way to #ifTrue:ifFalse:, is definitely doable and easy to implement. If you think it's more readable then it's the way to go. It does not extend the syntax so I think it can be done like that for the experiment as it is simpler to implement. > > Would indeed be more readable than :=: > > Phil > >> >> >>> In order to do this I will be modifying the VM and the Compiler . >>> >>> Good luck. This is an important step. >> >> >>> I'm working under the direction of INRIA and Gabriela ArÃ©valo. >>> >> >> Welcome! >> >> Thierry >> > >

Oct. 12, 2015

Re: [Pharo-dev] Problems with a large block

by Henrik Johansen

> On 12 Oct 2015, at 3:43 , Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > >> On 10 Oct 2015, at 10:05 , Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >> >> >> >> 2015-10-08 23:45 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>>: >> Hi Nicolai, >> >> On Thu, Oct 8, 2015 at 2:27 PM, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >> Hello Eliot, and thanks for your time. >> >> >> In our (pharo) implementation for sourceNodeForPC, we start at the AST-Node of >> the compiled method, get the IR (IntermediateRepresentation) and scan this sequence of IRNodes >> until we finally find that one, that maps to the bytecode of the closure creation code (this should be a IRPushClosureCopy). >> The problem is now, we don't find (always) the right IRNode, and it depens on the number of local temps, if this is > 3 we don't hit the right one. >> >> That's very strange. Can you construct a synthetic example of two simple blocks, one with three temps and and one with four temps and show me the difference in the byte code? >> >> >> [ :x | | a b c | a:=b:=c:=x ] "calling #sourceNode gives a RBBlockNode - ok" >> Bytecode >> 13 <8F 01 00 0B> closureNumCopied: 0 numArgs: 1 bytes 17 to 27 >> 17 <73> pushConstant: nil >> 18 <73> pushConstant: nil >> 19 <73> pushConstant: nil >> 20 <10> pushTemp: 0 >> 21 <81 43> storeIntoTemp: 3 >> 23 <81 42> storeIntoTemp: 2 >> 25 <81 41> storeIntoTemp: 1 >> 27 <7D> blockReturn >> 28 <7C> returnTop >> >> >> [ :x | | a b c d | a:=b:=c:=d:=x ] "calling #sourceNode gives a RBMethodNode - not ok" >> Bytecode >> 13 <8F 01 00 0E> closureNumCopied: 0 numArgs: 1 bytes 17 to 30 >> 17 <73> pushConstant: nil >> 18 <73> pushConstant: nil >> 19 <73> pushConstant: nil >> 20 <73> pushConstant: nil >> 21 <10> pushTemp: 0 >> 22 <81 44> storeIntoTemp: 4 >> 24 <81 43> storeIntoTemp: 3 >> 26 <81 42> storeIntoTemp: 2 >> 28 <81 41> storeIntoTemp: 1 >> 30 <7D> blockReturn >> 31 <7C> returnTop >> >> As I wrote above, in Pharo, to get the sourceNode we try to find the push closure bytecode from "startpc - 1" by traversing >> the IR and try to get the IRNode with matching "bytecodeOffset". The bytecodeOffsets for the above blocks: >> >> [ :x | | a b c | a:=b:=c:=x ] >> "bytecodeOffset -> IR" >> 19->pushClosureCopyCopiedValues: #() args: #(#x) >> 28->returnTop >> 20->pushTemp: #x >> 22->storeTemp: #c >> 24->storeTemp: #b >> 26->storeTemp: #a >> 27->blockReturnTop >> >> [ :x | | a b c d | a:=b:=c:=d:=x ] >> "bytecodeOffset -> IR" >> 20->pushClosureCopyCopiedValues: #() args: #(#x) >> 31->returnTop >> 21->pushTemp: #x >> 23->storeTemp: #d >> 25->storeTemp: #c >> 27->storeTemp: #b >> 29->storeTemp: #a >> 30->blockReturnTop >> >> Both blocks don't have a bytecodeOffset matching the bytecode of the pushclosure (13), but we start the search from "startpc - 1" (= 16) >> and do a loop from 0 to -3 (because bytecodes can have a length of 1,2 or 4) >> For the first block, this works >> bytecodeOffset 19 = 16 - (-3) >> For the second block this does not work, somehow the bytecodeoffset value depends on the number of local temps. And for the >> second block this is one greater. >> >> >> >> >> And my interpretation was, the IRPushClosureCopy node has the wrong "bytecode offset" (whatever this is). The bytecodeOffset value (somehow) >> depends on the number of local temps, but maybe this is right (for whatever this is used) and we are just using it wrong for in this situation. >> >> So you need to ask Marcus how to interpret bytecodeOffset. The thing is, it should be simple. One has: >> >> BlockCreationBytecode >> any number of pushConstant: nil's (0 to N) >> first byte code in block >> last bytecode in block (always a blockReturnTop) >> >> and a block's startup is always that of the byte immediately following the BlockCreationBytecode. So if the byte code offset is somehow the span of the "any number of pushConstant: nil's (0 to N)" then there's a bug in the IR somewhere when the number of temps is > 3. But if that's not what it means then, well, I don't know what the problem is. >> > > For some reason, bytecodeOffset is the *last* byte associated with IR. > This makes little sense to me, the main use seems to be to get correct offsets for different instructions in an IR sequence. > Since block IR includes temp initialization bytes, the offset is 5. > > Changing the code to record *starting* offset of an IRNode in IRSequence, by: > mapBytesTo: instr > "Associate the current byte offset with instr. We fix this later to have the correct offset, > see #bytecodes" > instrMap add: instr -> (bytes size + 1) > > and mapping bytes *before* visiting node in the IRTranslatorV2: > visitInstruction: instr > gen mapBytesTo: instr. > self visitNode: instr. > > and the same in visitPushClosureCopy: closure > closure copiedValues do: [:name | > gen mapBytesTo: closure. > gen pushTemp: (self currentScope indexForVarNamed: name). > > ]. > --snip-- Hupps, the pushing of copiedValues are not part of the closure bytecode, so that needs to be closure copiedValues do: [:name | gen pushTemp: (self currentScope indexForVarNamed: name). ]. gen mapBytesTo: closure. Thanks testBlockAndContextSourceNode! After a recompile of the test methods in case of cached IR (and offsets) (RPackageOrganizer default packageNamed: 'OpalCompiler-Tests') classes do:#recompile All (existing) tests are green with the attached change set (where haltOnce's were removed too), at least in the almost-release version of Pharo4 I tested in. Cheers, Henry

Oct. 12, 2015

Re: [Pharo-dev] Integer>>#putOn:

by Esteban Lorenzano

> On 12 Oct 2015, at 14:39, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 12 Oct 2015, at 14:26, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >> >> Hi, >> >> I just spotted this: >> >> >> Integer>>#putOn: aStream >> >> (aStream isBinary ifTrue: [ self asByteArray ] ifFalse: [ self asString]) putOn: aStream > > IMO, this is not good, implicit (and inefficient) conversions are being done. Why ? I donât knowâ¦ I was just passing through :) > > What is the exact contract of #putOn: anyway ? > > If the result should really depend on the argument, double dispatch might be better. > >> It does not look so bad at the begining, butâ¦ if I do: >> >> ByteArray streamContents: [ :s | 42 putOn: s ] >> >> I got an infinite loop. >> >> I know, it does not look as a very typical case, butâ¦ if Iâm writing to a Socket and I want to use >> >> mySocket << 255 âIACâ, thatâs exactly what will happen :( >> >> If I redefine it as: >> >> Integer>>#putOn: aStream >> aStream isBinary ifFalse: [ >> self asString putOn: aStream. >> ^ self ]. >> self asByteArray do: [ :each | aStream nextPut: each ] >> >> then is okâ¦ >> >> Would that be a good change? > > Yeah that looks about right, still weird, but no weirder than before ;-) I submitted a fix, still ugly but wellâ¦ at least it avoids the infinite loop :P > >> Esteban

Oct. 12, 2015

Re: [Pharo-dev] seg fault on Ubuntu when launching

by Robert Withers

That is precisely what I did. Here's the screenshot attached. My image 'warren4.1' is a Pharo 4.0 image. Robert On 10/12/2015 09:52 AM, phil(a)highoctane.be wrote: > I used these instructions: > > http://pharo.org/gnu-linux-installation#ubuntu-ppa-headless-vm > > Can you post a screenshot showing what you launch from the launcher? > > Phil > > On Mon, Oct 12, 2015 at 3:41 PM, Robert Withers > <robert.w.withers(a)gmail.com <mailto:robert.w.withers@gmail.com>> wrote: > > I am brand new to Ubuntu, as well. I am pretty lost with versions. > How would I check? I installed whatever came with apt-get. > > Oh, I tried a image/changes for the launcher dated 2015.09.14, if > that helps. It segfaulted. > > - Robert > > > On 10/12/2015 09:36 AM, phil(a)highoctane.be > <mailto:phil@highoctane.be> wrote: >> I am using Ubuntu 14.04 and Pharo Launcher without issues. >> >> Which image ? 4.0? >> >> Phil >> >> On Mon, Oct 12, 2015 at 3:27 PM, Robert Withers >> <robert.w.withers(a)gmail.com <mailto:robert.w.withers@gmail.com>> >> wrote: >> >> Hello, I am new to Pharo and just getting into it. >> >> I have Ubuntu and used PPA to install Pharo. The launcher is >> failing with a segfault crash.dmp when trying to launch. It >> is the UnixOSProcessAccessor>>forkAndExec... that is >> segaulting. I looked in /usr/lib/pharo-vm and do not see a >> UnixOSProcess plugin. Is it internal? >> >> I am able to launch an image from outside the launcher. >> >> -- >> thanks, >> Robert >> >> >> > > -- > thanks, > Robert > > -- thanks, Robert

Oct. 12, 2015

Re: [Pharo-dev] seg fault on Ubuntu when launching

by phil＠highoctane.be

I used these instructions: http://pharo.org/gnu-linux-installation#ubuntu-ppa-headless-vm Can you post a screenshot showing what you launch from the launcher? Phil On Mon, Oct 12, 2015 at 3:41 PM, Robert Withers <robert.w.withers(a)gmail.com> wrote: > I am brand new to Ubuntu, as well. I am pretty lost with versions. How > would I check? I installed whatever came with apt-get. > > Oh, I tried a image/changes for the launcher dated 2015.09.14, if that > helps. It segfaulted. > > - Robert > > > On 10/12/2015 09:36 AM, phil(a)highoctane.be wrote: > > I am using Ubuntu 14.04 and Pharo Launcher without issues. > > Which image ? 4.0? > > Phil > > On Mon, Oct 12, 2015 at 3:27 PM, Robert Withers < > robert.w.withers(a)gmail.com> wrote: > >> Hello, I am new to Pharo and just getting into it. >> >> I have Ubuntu and used PPA to install Pharo. The launcher is failing with >> a segfault crash.dmp when trying to launch. It is the >> UnixOSProcessAccessor>>forkAndExec... that is segaulting. I looked in >> /usr/lib/pharo-vm and do not see a UnixOSProcess plugin. Is it internal? >> >> I am able to launch an image from outside the launcher. >> >> -- >> thanks, >> Robert >> >> >> > > -- > thanks, > Robert > >

Oct. 12, 2015

Re: [Pharo-dev] [ANN] Cupboard inspector for Teapot

by phil＠highoctane.be

Very nice! Will come handy for me next monday (hackathon time). Phil On Mon, Oct 12, 2015 at 3:37 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > I took a few minutes to add a custom inspector tool ("Cupboard") to > Teapot showing all the available teapots. The tool is accessible from the > Tool menu right after loading "Teapot" and allows get an overview on > running teapots. > If you teapot has dynamic routes they will be shown as well. See screenshot > attached. > > You can also start/stop a Teapot or add a new one serving static > contents from a selected directory. > > Also catalog messages were added to the ConfigurationOfTeapot and the > NeoJSON repo in the dependencies was fixed. > > Just get the lates stable version: > > Gofer it > smalltalkhubUser: 'zeroflag' project: 'Teapot'; > configuration; > loadStable. > > or directly load from ConfigBrowser (Pharo 4) or CatalogBrowser/Spotter > (Pharo 5) > in a fresh image. > > > If you want to quickly serve a (static) webpage from Pharo > ========================================================== > Create a web directory and HTML page > - use "Tools" -> "File Browser" > - create a directory "www" using "Add new directory", navigate to it > - create a new file "index.html" using "Add new file", edit it and > accept the changes > > Serve it from Pharo > - load Teapot in a fresh image > - open "Tools" -> "Teapot" > - click on the server icon on the right to create a new static server > - accept the default port 80 or enter a new one > - select the directory > > Point your browser to http://localhost:80 > > If you want to quickly server (dynamic) content from Pharo: > =========================================================== > - use one of the examples on http://smalltalkhub.com/#!/~zeroflag/Teapot > Note that the dynamic routes are shown in the new tool > > Tip: if you like use "Mustache" template library to mix HTML content > (like Bootstrap templates, Material design templates or other > with your Pharo server objects to serve pages) > > Have fun > T.

Oct. 12, 2015

Re: [Pharo-dev] [Pharo-users] [ANN] Cupboard inspector for Teapot

by Tudor Girba

You really are having fun :). Nice! Doru On Mon, Oct 12, 2015 at 3:37 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > I took a few minutes to add a custom inspector tool ("Cupboard") to > Teapot showing all the available teapots. The tool is accessible from the > Tool menu right after loading "Teapot" and allows get an overview on > running teapots. > If you teapot has dynamic routes they will be shown as well. See screenshot > attached. > > You can also start/stop a Teapot or add a new one serving static > contents from a selected directory. > > Also catalog messages were added to the ConfigurationOfTeapot and the > NeoJSON repo in the dependencies was fixed. > > Just get the lates stable version: > > Gofer it > smalltalkhubUser: 'zeroflag' project: 'Teapot'; > configuration; > loadStable. > > or directly load from ConfigBrowser (Pharo 4) or CatalogBrowser/Spotter > (Pharo 5) > in a fresh image. > > > If you want to quickly serve a (static) webpage from Pharo > ========================================================== > Create a web directory and HTML page > - use "Tools" -> "File Browser" > - create a directory "www" using "Add new directory", navigate to it > - create a new file "index.html" using "Add new file", edit it and > accept the changes > > Serve it from Pharo > - load Teapot in a fresh image > - open "Tools" -> "Teapot" > - click on the server icon on the right to create a new static server > - accept the default port 80 or enter a new one > - select the directory > > Point your browser to http://localhost:80 > > If you want to quickly server (dynamic) content from Pharo: > =========================================================== > - use one of the examples on http://smalltalkhub.com/#!/~zeroflag/Teapot > Note that the dynamic routes are shown in the new tool > > Tip: if you like use "Mustache" template library to mix HTML content > (like Bootstrap templates, Material design templates or other > with your Pharo server objects to serve pages) > > Have fun > T. -- www.tudorgirba.com "Every thing has its own flow"

Oct. 12, 2015

Re: [Pharo-dev] Problems with a large block

by Henrik Johansen

> On 10 Oct 2015, at 10:05 , Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2015-10-08 23:45 GMT+02:00 Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>>: > Hi Nicolai, > > On Thu, Oct 8, 2015 at 2:27 PM, Nicolai Hess <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: > Hello Eliot, and thanks for your time. > > > In our (pharo) implementation for sourceNodeForPC, we start at the AST-Node of > the compiled method, get the IR (IntermediateRepresentation) and scan this sequence of IRNodes > until we finally find that one, that maps to the bytecode of the closure creation code (this should be a IRPushClosureCopy). > The problem is now, we don't find (always) the right IRNode, and it depens on the number of local temps, if this is > 3 we don't hit the right one. > > That's very strange. Can you construct a synthetic example of two simple blocks, one with three temps and and one with four temps and show me the difference in the byte code? > > > [ :x | | a b c | a:=b:=c:=x ] "calling #sourceNode gives a RBBlockNode - ok" > Bytecode > 13 <8F 01 00 0B> closureNumCopied: 0 numArgs: 1 bytes 17 to 27 > 17 <73> pushConstant: nil > 18 <73> pushConstant: nil > 19 <73> pushConstant: nil > 20 <10> pushTemp: 0 > 21 <81 43> storeIntoTemp: 3 > 23 <81 42> storeIntoTemp: 2 > 25 <81 41> storeIntoTemp: 1 > 27 <7D> blockReturn > 28 <7C> returnTop > > > [ :x | | a b c d | a:=b:=c:=d:=x ] "calling #sourceNode gives a RBMethodNode - not ok" > Bytecode > 13 <8F 01 00 0E> closureNumCopied: 0 numArgs: 1 bytes 17 to 30 > 17 <73> pushConstant: nil > 18 <73> pushConstant: nil > 19 <73> pushConstant: nil > 20 <73> pushConstant: nil > 21 <10> pushTemp: 0 > 22 <81 44> storeIntoTemp: 4 > 24 <81 43> storeIntoTemp: 3 > 26 <81 42> storeIntoTemp: 2 > 28 <81 41> storeIntoTemp: 1 > 30 <7D> blockReturn > 31 <7C> returnTop > > As I wrote above, in Pharo, to get the sourceNode we try to find the push closure bytecode from "startpc - 1" by traversing > the IR and try to get the IRNode with matching "bytecodeOffset". The bytecodeOffsets for the above blocks: > > [ :x | | a b c | a:=b:=c:=x ] > "bytecodeOffset -> IR" > 19->pushClosureCopyCopiedValues: #() args: #(#x) > 28->returnTop > 20->pushTemp: #x > 22->storeTemp: #c > 24->storeTemp: #b > 26->storeTemp: #a > 27->blockReturnTop > > [ :x | | a b c d | a:=b:=c:=d:=x ] > "bytecodeOffset -> IR" > 20->pushClosureCopyCopiedValues: #() args: #(#x) > 31->returnTop > 21->pushTemp: #x > 23->storeTemp: #d > 25->storeTemp: #c > 27->storeTemp: #b > 29->storeTemp: #a > 30->blockReturnTop > > Both blocks don't have a bytecodeOffset matching the bytecode of the pushclosure (13), but we start the search from "startpc - 1" (= 16) > and do a loop from 0 to -3 (because bytecodes can have a length of 1,2 or 4) > For the first block, this works > bytecodeOffset 19 = 16 - (-3) > For the second block this does not work, somehow the bytecodeoffset value depends on the number of local temps. And for the > second block this is one greater. > > > > > And my interpretation was, the IRPushClosureCopy node has the wrong "bytecode offset" (whatever this is). The bytecodeOffset value (somehow) > depends on the number of local temps, but maybe this is right (for whatever this is used) and we are just using it wrong for in this situation. > > So you need to ask Marcus how to interpret bytecodeOffset. The thing is, it should be simple. One has: > > BlockCreationBytecode > any number of pushConstant: nil's (0 to N) > first byte code in block > last bytecode in block (always a blockReturnTop) > > and a block's startup is always that of the byte immediately following the BlockCreationBytecode. So if the byte code offset is somehow the span of the "any number of pushConstant: nil's (0 to N)" then there's a bug in the IR somewhere when the number of temps is > 3. But if that's not what it means then, well, I don't know what the problem is. > For some reason, bytecodeOffset is the *last* byte associated with IR. This makes little sense to me, the main use seems to be to get correct offsets for different instructions in an IR sequence. Since block IR includes temp initialization bytes, the offset is 5. Changing the code to record *starting* offset of an IRNode in IRSequence, by: mapBytesTo: instr "Associate the current byte offset with instr. We fix this later to have the correct offset, see #bytecodes" instrMap add: instr -> (bytes size + 1) and mapping bytes *before* visiting node in the IRTranslatorV2: visitInstruction: instr gen mapBytesTo: instr. self visitNode: instr. and the same in visitPushClosureCopy: closure closure copiedValues do: [:name | gen mapBytesTo: closure. gen pushTemp: (self currentScope indexForVarNamed: name). ]. --snip-- Plus changing IRMethod >> instructionForPC: aPC to scan backwards to find the start of in-mid PC (for now up to 3 bytes): self compiledMethod. "generates the compiledMethod and optimize the ir. Removes the side-effect of optimizing the IR while looking for instruction, which results in incorrect found instruction" self haltOnce. 0 to: 3 do: [ :off | (self firstInstructionMatching: [:ir | ir bytecodeOffset = (aPC - off) ]) ifNotNil: [:it |^it]] We get more sensible results from the above tests for argumentNames/sourceNode. Amazingly, debugger range hilighting seems to keep working as well :) Cheers, Henry

Oct. 12, 2015

Re: [Pharo-dev] seg fault on Ubuntu when launching

by Robert Withers

I am brand new to Ubuntu, as well. I am pretty lost with versions. How would I check? I installed whatever came with apt-get. Oh, I tried a image/changes for the launcher dated 2015.09.14, if that helps. It segfaulted. - Robert On 10/12/2015 09:36 AM, phil(a)highoctane.be wrote: > I am using Ubuntu 14.04 and Pharo Launcher without issues. > > Which image ? 4.0? > > Phil > > On Mon, Oct 12, 2015 at 3:27 PM, Robert Withers > <robert.w.withers(a)gmail.com <mailto:robert.w.withers@gmail.com>> wrote: > > Hello, I am new to Pharo and just getting into it. > > I have Ubuntu and used PPA to install Pharo. The launcher is > failing with a segfault crash.dmp when trying to launch. It is the > UnixOSProcessAccessor>>forkAndExec... that is segaulting. I > looked in /usr/lib/pharo-vm and do not see a UnixOSProcess plugin. > Is it internal? > > I am able to launch an image from outside the launcher. > > -- > thanks, > Robert > > > -- thanks, Robert

Oct. 12, 2015

[ANN] Cupboard inspector for Teapot

by Torsten Bergmann

Hi, I took a few minutes to add a custom inspector tool ("Cupboard") to Teapot showing all the available teapots. The tool is accessible from the Tool menu right after loading "Teapot" and allows get an overview on running teapots. If you teapot has dynamic routes they will be shown as well. See screenshot attached. You can also start/stop a Teapot or add a new one serving static contents from a selected directory. Also catalog messages were added to the ConfigurationOfTeapot and the NeoJSON repo in the dependencies was fixed. Just get the lates stable version: Gofer it smalltalkhubUser: 'zeroflag' project: 'Teapot'; configuration; loadStable. or directly load from ConfigBrowser (Pharo 4) or CatalogBrowser/Spotter (Pharo 5) in a fresh image. If you want to quickly serve a (static) webpage from Pharo ========================================================== Create a web directory and HTML page - use "Tools" -> "File Browser" - create a directory "www" using "Add new directory", navigate to it - create a new file "index.html" using "Add new file", edit it and accept the changes Serve it from Pharo - load Teapot in a fresh image - open "Tools" -> "Teapot" - click on the server icon on the right to create a new static server - accept the default port 80 or enter a new one - select the directory Point your browser to http://localhost:80 If you want to quickly server (dynamic) content from Pharo: =========================================================== - use one of the examples on http://smalltalkhub.com/#!/~zeroflag/Teapot Note that the dynamic routes are shown in the new tool Tip: if you like use "Mustache" template library to mix HTML content (like Bootstrap templates, Material design templates or other with your Pharo server objects to serve pages) Have fun T.

Oct. 12, 2015

Re: [Pharo-dev] seg fault on Ubuntu when launching

by phil＠highoctane.be

I am using Ubuntu 14.04 and Pharo Launcher without issues. Which image ? 4.0? Phil On Mon, Oct 12, 2015 at 3:27 PM, Robert Withers <robert.w.withers(a)gmail.com> wrote: > Hello, I am new to Pharo and just getting into it. > > I have Ubuntu and used PPA to install Pharo. The launcher is failing with > a segfault crash.dmp when trying to launch. It is the > UnixOSProcessAccessor>>forkAndExec... that is segaulting. I looked in > /usr/lib/pharo-vm and do not see a UnixOSProcess plugin. Is it internal? > > I am able to launch an image from outside the launcher. > > -- > thanks, > Robert > > >

Oct. 12, 2015

Re: [Pharo-dev] hello

by phil＠highoctane.be

On Mon, Oct 12, 2015 at 3:20 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Hi SebastiÃ n, > > 2015-10-12 13:53 GMT+02:00 SebastiÃ¡n Krynski <skrynski(a)gmail.com>: > >> Hello my name is SebastiÃ¡n Krynski from Buenos Aires, Argentina. >> Just writing to let you know that I'm starting to work on adding an >> atomic swap operator in Pharo , guaranteed not to be interrupted by the VM. >> The operator will be used this way: >> >> a :=: b >> >> meaning 'swap variable a with variable b'. >> > > Why a cryptic, special syntax? The compiler could inline an explicit > message send which would make the intent clear. > See previous discussions about <=> indeed. > > a atomicSwapWith: b. > > Well, anyway, the compiler has to do something special there. > > Could we have something like... > > [ | temp | > temp := a. > a := b. > b := a ] atomic > > ? Would a compiler be able to merge that in a swap instruction? And make > another type of processing for a different code inside the block? > We have Mutex>>critical: aBlock etc. Why not Atomic>>do: aBlock ? Would indeed be more readable than :=: Phil > > >> In order to do this I will be modifying the VM and the Compiler . >> >> Good luck. This is an important step. > > >> I'm working under the direction of INRIA and Gabriela ArÃ©valo. >> > > Welcome! > > Thierry >

Oct. 12, 2015

seg fault on Ubuntu when launching

by Robert Withers

Hello, I am new to Pharo and just getting into it. I have Ubuntu and used PPA to install Pharo. The launcher is failing with a segfault crash.dmp when trying to launch. It is the UnixOSProcessAccessor>>forkAndExec... that is segaulting. I looked in /usr/lib/pharo-vm and do not see a UnixOSProcess plugin. Is it internal? I am able to launch an image from outside the launcher. -- thanks, Robert

Oct. 12, 2015

Re: [Pharo-dev] hello

by Thierry Goubier

Hi SebastiÃ n, 2015-10-12 13:53 GMT+02:00 SebastiÃ¡n Krynski <skrynski(a)gmail.com>: > Hello my name is SebastiÃ¡n Krynski from Buenos Aires, Argentina. > Just writing to let you know that I'm starting to work on adding an atomic > swap operator in Pharo , guaranteed not to be interrupted by the VM. The > operator will be used this way: > > a :=: b > > meaning 'swap variable a with variable b'. > Why a cryptic, special syntax? The compiler could inline an explicit message send which would make the intent clear. a atomicSwapWith: b. Well, anyway, the compiler has to do something special there. Could we have something like... [ | temp | temp := a. a := b. b := a ] atomic ? Would a compiler be able to merge that in a swap instruction? And make another type of processing for a different code inside the block? > In order to do this I will be modifying the VM and the Compiler . > > Good luck. This is an important step. > I'm working under the direction of INRIA and Gabriela ArÃ©valo. > Welcome! Thierry

Oct. 12, 2015

Re: [Pharo-dev] hello

by Max Leske

> On 12 Oct 2015, at 14:47, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Hello, > > If the operator is atomic that means if another thread (I am talking about native threads) interacts with the same portion of memory than the active thread its operation will be done after of before. This is a step toward a multithreaded VM with lock free algorithms and is different from just having a user interrupt or a process switch. #become: or the multiple assignments you showed are done in several cpu instructions hence another thread can manipulate the same memory while the operation is performed, which is not atomic. > > Hence, the way I understand it is that the operation :=: is done in 1 cpu instruction. SebastiÃ¡n has to change the bytecode compiler, the JIT and the interpreter to support that. That cannot be done with any variable, but it may be possible to implement :=: for at least 2 temporaries using the cpu swap. > > There is still a long way to go to have a multithreaded VM with lock-free algorithms, but one has to start somewhere I guess. I am not expert in concurrent programming but atomic swap or test and set operations are probably the way to go. I see. That does make sense. Thanks Clement. > > Cheers, > > Clement > > > > 2015-10-12 14:12 GMT+02:00 Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>>: > >> On 12 Oct 2015, at 13:53, SebastiÃ¡n Krynski <skrynski(a)gmail.com <mailto:skrynski@gmail.com>> wrote: >> >> Hello my name is SebastiÃ¡n Krynski from Buenos Aires, Argentina. > > Hi SebastiÃ¡n, welcome! > >> Just writing to let you know that I'm starting to work on adding an atomic swap operator in Pharo , guaranteed not to be interrupted by the VM. The operator will be used this way: >> >> a :=: b >> >> meaning 'swap variable a with variable b'. >> In order to do this I will be modifying the VM and the Compiler . > > Sound cool! But isnât that the same as > > a become: b > > ? I even think that > > tmp := a. > a := b. > b := tmp > > is equivalent, since the VM only interrupts message sends, and in this case only byte code would be generated? > > Thatâs not my area of expertise, so please correct me. > > Cheers, > Max > >> >> I'm working under the direction of INRIA and Gabriela ArÃ©valo. >> > >

Oct. 12, 2015

Re: [Pharo-dev] hello

by ClÃ©ment Bera

Hello, If the operator is atomic that means if another thread (I am talking about native threads) interacts with the same portion of memory than the active thread its operation will be done after of before. This is a step toward a multithreaded VM with lock free algorithms and is different from just having a user interrupt or a process switch. #become: or the multiple assignments you showed are done in several cpu instructions hence another thread can manipulate the same memory while the operation is performed, which is not atomic. Hence, the way I understand it is that the operation :=: is done in 1 cpu instruction. SebastiÃ¡n has to change the bytecode compiler, the JIT and the interpreter to support that. That cannot be done with any variable, but it may be possible to implement :=: for at least 2 temporaries using the cpu swap. There is still a long way to go to have a multithreaded VM with lock-free algorithms, but one has to start somewhere I guess. I am not expert in concurrent programming but atomic swap or test and set operations are probably the way to go. Cheers, Clement 2015-10-12 14:12 GMT+02:00 Max Leske <maxleske(a)gmail.com>: > > On 12 Oct 2015, at 13:53, SebastiÃ¡n Krynski <skrynski(a)gmail.com> wrote: > > Hello my name is SebastiÃ¡n Krynski from Buenos Aires, Argentina. > > > Hi SebastiÃ¡n, welcome! > > Just writing to let you know that I'm starting to work on adding an atomic > swap operator in Pharo , guaranteed not to be interrupted by the VM. The > operator will be used this way: > > a :=: b > > meaning 'swap variable a with variable b'. > In order to do this I will be modifying the VM and the Compiler . > > > Sound cool! But isnât that the same as > > a become: b > > ? I even think that > > tmp := a. > a := b. > b := tmp > > is equivalent, since the VM only interrupts message sends, and in this > case only byte code would be generated? > > Thatâs not my area of expertise, so please correct me. > > Cheers, > Max > > > I'm working under the direction of INRIA and Gabriela ArÃ©valo. > > >

Oct. 12, 2015