July 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [ANN] file dialog replacement experiment

by Peter UhnÃ¡k

Hi Sven, What I am missing in the UI is some indication of the path that leads to > the current selected file. Right now, I am wondering where exactly I am, I > feel a bit lost (this is of course from the technical standpoint of a path > in a tree). This could be done with a popup, a trail, a pop-over. > I've added this couple of days ago (as I was missing this too), I just forgot to push the update to github (one downside compared to smalltalkhub :)). The only problem is that the image directory name is usually really long (the longest I have is 110 characters as it includes the build's name), so it doesn't exactly fit in. There is some shortening happening based on the window's width but it's not perfect. What I like is what zenity does (clickable path)â¦ but it automatically widens the window â Peter > > We should have some more discussions about this, it could make a great > addition to Pharo. > > Sven > > > On 11 Jun 2016, at 02:45, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > Hi, > > > > last week I stitched together a simple file dialog replacement and today > I managed to somewhat finish it. > > > > There is still a lot to be desired, but right now it supports things > that were the most pain for me: > > > > * list of most common places (home, root, image directory, temp) > > * custom bookmarks by dragging folders from file-pane to bookmark-pane > > * toggle hidden files (right-click on file listing) > > * preset file name > > * filtering files by extensions or patterns and toggling between filters > > * synchronous and asynchronous mode > > > > > > <file-dialog-3.png> > > â > > You can use it independently of Pharo's native dialogs > > > > FDOpenFileDialog new > > extensionFilters: > > {'STON files' -> #(ston). > > 'All files' -> #()}; > > defaultFolder: FileLocator imageDirectory asFileReference; > > openModal > > > > Or if you feel brave, I have an extended UIManager that will use thisâ¦, > and then you can use regular manager commands > > > > UIManager default chooseFileMatching: #('*.ston') > > > > but you can always go back > > > > FDMorphicUIManager new beDefault. "use new dialogs" > > MorphicUIManager new beDefault. "use old dialogs" > > > > and of course the installation itself (I'll add it to catalog soon after > I find a way to autogenerate configurations from git tags) > > > > Metacello new > > baseline: 'FileDialog'; > > repository: 'github://peteruhnak/file-dialog/repository'; > > load. > > > > More info and docs on GitHub https://github.com/peteruhnak/file-dialog > > > > Any comments/feedback/bug reports is appreciated. > > > > Peter > > >

July 14, 2016

Re: [Pharo-dev] [ANN] file dialog replacement experiment

by Sven Van Caekenberghe

Peter, This is really well done ! This should be used as an example on how to use Spec for something real. What I am missing in the UI is some indication of the path that leads to the current selected file. Right now, I am wondering where exactly I am, I feel a bit lost (this is of course from the technical standpoint of a path in a tree). This could be done with a popup, a trail, a pop-over. We should have some more discussions about this, it could make a great addition to Pharo. Sven > On 11 Jun 2016, at 02:45, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > last week I stitched together a simple file dialog replacement and today I managed to somewhat finish it. > > There is still a lot to be desired, but right now it supports things that were the most pain for me: > > * list of most common places (home, root, image directory, temp) > * custom bookmarks by dragging folders from file-pane to bookmark-pane > * toggle hidden files (right-click on file listing) > * preset file name > * filtering files by extensions or patterns and toggling between filters > * synchronous and asynchronous mode > > > <file-dialog-3.png> > â > You can use it independently of Pharo's native dialogs > > FDOpenFileDialog new > extensionFilters: > {'STON files' -> #(ston). > 'All files' -> #()}; > defaultFolder: FileLocator imageDirectory asFileReference; > openModal > > Or if you feel brave, I have an extended UIManager that will use thisâ¦, and then you can use regular manager commands > > UIManager default chooseFileMatching: #('*.ston') > > but you can always go back > > FDMorphicUIManager new beDefault. "use new dialogs" > MorphicUIManager new beDefault. "use old dialogs" > > and of course the installation itself (I'll add it to catalog soon after I find a way to autogenerate configurations from git tags) > > Metacello new > baseline: 'FileDialog'; > repository: 'github://peteruhnak/file-dialog/repository'; > load. > > More info and docs on GitHub https://github.com/peteruhnak/file-dialog > > Any comments/feedback/bug reports is appreciated. > > Peter

July 14, 2016

Re: [Pharo-dev] What is the correct way to create new integration configuration?

by Juraj Kubelka

OK. Thanks Marcus! > El 14-07-2016, a las 12:32, Marcus Denker <marcus.denker(a)inria.fr> escribiÃ³: > > Hello, > > the CI is sadly down (admins fixed something yesterday evening to make it work again, but > it still does not work). > > There is a long weekend here (holiday today), so this might only be fixed monday. > > > Marcus > >> On 14 Jul 2016, at 18:00, Juraj Kubelka <juraj.kubelka(a)icloud.com <mailto:juraj.kubelka@icloud.com>> wrote: >> >> Can someone check if I created well the GTool integration? >> >> - https://pharo.fogbugz.com/f/cases/18773/ <https://pharo.fogbugz.com/f/cases/18773/> >> >> I do not know if Monkey should run it. Maybe I miss something. >> It is in the state Resolved (Fix Review Needed). >> >> Thanks, >> Juraj >> >>> El 13-07-2016, a las 10:06, Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> escribiÃ³: >>> >>> Thanks a lot, Juraj! >>> >>> Doru >>> >>> >>>> On Jul 13, 2016, at 3:45 PM, Juraj Kubelka <juraj.kubelka(a)icloud.com <mailto:juraj.kubelka@icloud.com>> wrote: >>>> >>>>> >>>>> 13. 7. 2016 v 9:32, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: >>>>> >>>>> >>>>>> On 13 Jul 2016, at 14:46, Juraj Kubelka <juraj.kubelka(a)icloud.com <mailto:juraj.kubelka@icloud.com>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I am working on a new configuration for GTools. >>>>>> >>>>>> What is the correct way to integrate cases with a slice? >>>>>> For example this one: https://pharo.fogbugz.com/f/cases/18471/GTTools-relies-on-hasSpecialSelecto… <https://pharo.fogbugz.com/f/cases/18471/GTTools-relies-on-hasSpecialSelecto…> >>>>>> It has slice in Pharo60Inbox. Should I copy commits to GToolkit repository? >>>>>> >>>>> This one is not yet integrated, I submitted a slice to not have to wait for GT, but with my pre-holiday stress I did not menage to actually >>>>> get it in yet. >>>>> >>>>> So instead you can ignore the slice and just get these changes in. >>>> >>>> OK. I am preparing new configuration here: https://pharo.fogbugz.com/f/cases/18773/ <https://pharo.fogbugz.com/f/cases/18773/> >>>> I am almost done. >>>> I will take care of GTool integrations. So next time there is something to integrate, just ping me. Anyway, i will regularly check FogBugz. >>>> >>>>> >>>>>> And how it happens that GToolkit repository has commits done by TheIntegrator? >>>>> >>>>> The auto-rewriting deprecations happen to rewrite code. This then is saved in the Pharo repo and needs to be merged. >>>>> (or if it is the latest it can just be copied). >>>>> >>>>> The same happens if changes have to be done fast or if they cross-cut many packages. >>>>> >>>>> it is a bit of a messâ¦ for the future we need a unified way to handle thingsâ¦ the current approach with the configurations and >>>>> external repositories is not good.. far too slow and far too much manual work. >>>> >>>> Thatâs true. It is a lot of manual work and it is also hard to know if I integrate it well, with all changes, etc. >>>> >>>> Cheers, >>>> Juraj >>>> >>>>> >>>>> Marcus >>> >>> -- >>> www.tudorgirba.com <http://www.tudorgirba.com/> >>> www.feenk.com <http://www.feenk.com/> >>> >>> "When people care, great things can happen." >>> >>> >>> >>> >>> >> >

July 14, 2016

Re: [Pharo-dev] What is the correct way to create new integration configuration?

by Marcus Denker

Hello, the CI is sadly down (admins fixed something yesterday evening to make it work again, but it still does not work). There is a long weekend here (holiday today), so this might only be fixed monday. Marcus > On 14 Jul 2016, at 18:00, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: > > Can someone check if I created well the GTool integration? > > - https://pharo.fogbugz.com/f/cases/18773/ <https://pharo.fogbugz.com/f/cases/18773/> > > I do not know if Monkey should run it. Maybe I miss something. > It is in the state Resolved (Fix Review Needed). > > Thanks, > Juraj > >> El 13-07-2016, a las 10:06, Tudor Girba <tudor(a)tudorgirba.com <mailto:tudor@tudorgirba.com>> escribiÃ³: >> >> Thanks a lot, Juraj! >> >> Doru >> >> >>> On Jul 13, 2016, at 3:45 PM, Juraj Kubelka <juraj.kubelka(a)icloud.com <mailto:juraj.kubelka@icloud.com>> wrote: >>> >>>> >>>> 13. 7. 2016 v 9:32, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>>: >>>> >>>> >>>>> On 13 Jul 2016, at 14:46, Juraj Kubelka <juraj.kubelka(a)icloud.com <mailto:juraj.kubelka@icloud.com>> wrote: >>>>> >>>>> Hi, >>>>> >>>>> I am working on a new configuration for GTools. >>>>> >>>>> What is the correct way to integrate cases with a slice? >>>>> For example this one: https://pharo.fogbugz.com/f/cases/18471/GTTools-relies-on-hasSpecialSelecto… <https://pharo.fogbugz.com/f/cases/18471/GTTools-relies-on-hasSpecialSelecto…> >>>>> It has slice in Pharo60Inbox. Should I copy commits to GToolkit repository? >>>>> >>>> This one is not yet integrated, I submitted a slice to not have to wait for GT, but with my pre-holiday stress I did not menage to actually >>>> get it in yet. >>>> >>>> So instead you can ignore the slice and just get these changes in. >>> >>> OK. I am preparing new configuration here: https://pharo.fogbugz.com/f/cases/18773/ <https://pharo.fogbugz.com/f/cases/18773/> >>> I am almost done. >>> I will take care of GTool integrations. So next time there is something to integrate, just ping me. Anyway, i will regularly check FogBugz. >>> >>>> >>>>> And how it happens that GToolkit repository has commits done by TheIntegrator? >>>> >>>> The auto-rewriting deprecations happen to rewrite code. This then is saved in the Pharo repo and needs to be merged. >>>> (or if it is the latest it can just be copied). >>>> >>>> The same happens if changes have to be done fast or if they cross-cut many packages. >>>> >>>> it is a bit of a messâ¦ for the future we need a unified way to handle thingsâ¦ the current approach with the configurations and >>>> external repositories is not good.. far too slow and far too much manual work. >>> >>> Thatâs true. It is a lot of manual work and it is also hard to know if I integrate it well, with all changes, etc. >>> >>> Cheers, >>> Juraj >>> >>>> >>>> Marcus >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com/> >> www.feenk.com >> >> "When people care, great things can happen." >> >> >> >> >> >

July 14, 2016

Re: [Pharo-dev] What is the correct way to create new integration configuration?

by Juraj Kubelka

Can someone check if I created well the GTool integration? - https://pharo.fogbugz.com/f/cases/18773/ <https://pharo.fogbugz.com/f/cases/18773/> I do not know if Monkey should run it. Maybe I miss something. It is in the state Resolved (Fix Review Needed). Thanks, Juraj > El 13-07-2016, a las 10:06, Tudor Girba <tudor(a)tudorgirba.com> escribiÃ³: > > Thanks a lot, Juraj! > > Doru > > >> On Jul 13, 2016, at 3:45 PM, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: >> >>> >>> 13. 7. 2016 v 9:32, Marcus Denker <marcus.denker(a)inria.fr>: >>> >>> >>>> On 13 Jul 2016, at 14:46, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: >>>> >>>> Hi, >>>> >>>> I am working on a new configuration for GTools. >>>> >>>> What is the correct way to integrate cases with a slice? >>>> For example this one: https://pharo.fogbugz.com/f/cases/18471/GTTools-relies-on-hasSpecialSelecto… >>>> It has slice in Pharo60Inbox. Should I copy commits to GToolkit repository? >>>> >>> This one is not yet integrated, I submitted a slice to not have to wait for GT, but with my pre-holiday stress I did not menage to actually >>> get it in yet. >>> >>> So instead you can ignore the slice and just get these changes in. >> >> OK. I am preparing new configuration here: https://pharo.fogbugz.com/f/cases/18773/ >> I am almost done. >> I will take care of GTool integrations. So next time there is something to integrate, just ping me. Anyway, i will regularly check FogBugz. >> >>> >>>> And how it happens that GToolkit repository has commits done by TheIntegrator? >>> >>> The auto-rewriting deprecations happen to rewrite code. This then is saved in the Pharo repo and needs to be merged. >>> (or if it is the latest it can just be copied). >>> >>> The same happens if changes have to be done fast or if they cross-cut many packages. >>> >>> it is a bit of a messâ¦ for the future we need a unified way to handle thingsâ¦ the current approach with the configurations and >>> external repositories is not good.. far too slow and far too much manual work. >> >> Thatâs true. It is a lot of manual work and it is also hard to know if I integrate it well, with all changes, etc. >> >> Cheers, >> Juraj >> >>> >>> Marcus > > -- > www.tudorgirba.com > www.feenk.com > > "When people care, great things can happen." > > > > >

July 14, 2016

Re: [Pharo-dev] [Pharo-users] Download link for latest Pharo6 image on download page

by Alexandre Bergel

Thanks!! This is useful Alexandre > On Jul 14, 2016, at 11:02 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > I have added a link to the download page for Pharo6: > > http://pharo.org/download > > This way it is easier to findâ¦ it is of course in active development, but quite usable > most of the time. > > Marcus -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 14, 2016

Re: [Pharo-dev] [Pharo-users] Download link for latest Pharo6 image on download page

by Marcus Denker

I think there is not yetâ¦ There will be more coming in this direction soon. > On 14 Jul 2016, at 11:09, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > Thank you Marcus, where we can find more info about the Pharo Minimal Image ? > > On Thu, Jul 14, 2016 at 12:04 PM Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > Hi, > > I have added a link to the download page for Pharo6: > > http://pharo.org/download <http://pharo.org/download> > > This way it is easier to findâ¦ it is of course in active development, but quite usable > most of the time. > > Marcus

July 14, 2016

Re: [Pharo-dev] tricks for XML parsing.

by Jan Vrany

On Thu, 2016-07-14 at 11:11 +0200, monty wrote: > > > Sent: Thursday, July 14, 2016 at 2:50 AM > > From: "Jan Vrany" <jan.vrany(a)fit.cvut.cz> > > To: pharo-dev(a)lists.pharo.org > > Subject: Re: [Pharo-dev] tricks for XML parsing. > > > > On Thu, 2016-07-14 at 01:58 +0200, monty wrote: > > > Thanks for the link. > > > > > > In-place parsing is a non-starter because it means storing the > > > entire > > > input as a string in memory, so you could only parse files that > > > fit > > > in Pharo's address space. The multi-gigabyte OpenStreetMap docs > > > the > > > article mentions would be unparsable with SAX in a 32-bit VM. > > > > I do not understand. I only know expat which does - AFAIK - in- > > place > > parsing and surelt does not need the whole input in memory.Â > > From the article, footnote 3: "This creates a lifetime dependencyâthe > entire source buffer must outlive all document nodes for the > technique to work" Ah, I see. I assumed that the consumer would copy data if it needs to retain them...then the parser can do in-place tricks.Â Perhaps the difference is that I do not consider creation of a DOM being part of "parsing" (I'm not saying it's not, just that this is a way I think of the problem which may cause confusion :-)Â > > > > There is always the option of an FFI-based parser, but it > > > shouldn't > > > be a hybrid like Python's minidom (FFI Expat with a Python DOM > > > implementation),Â > > > because something like that already exists in Smalltalk/X (FFI > > > Expat > > > with a Smalltalk DOM)Â > > > > I guess you refer to the implementation I did ages ago.Â > > > > > and it was slower than a St/X port of XMLParser in my tests (I > > > assume > > > due to the FFI overhead), so it's probably not worth it.Â > > > > Very, very interesting. Where can I find the benchmarks?Â > > This was well over a year ago, and it was DOM parsing. I was testing > if St/X (your branch, I think) could be supported by XMLParser in > addition to Pharo, Squeak, and GS, but I ran into too many > incompatibilities, like Monticello not working (had to load in .st > files), #new not sending #initialize, not being able to modify the > value of a dictionary association directly, #lf/#cr weirdness, so I > gave up. But not before hacking it enough to kind-of run and compared > it with the other parsers. Fair enough. If you want to discuss these problems, Â I'd be happy to help. > > > I just run a very simple benchmark on 112MB document (http://www.xm > > l-be > > nchmark.org/downloads.html) and results are quite the opposite:Â > > > > Benchmark resut: > > Generated at :14-07-2016 07:32:25 AM > > > > Â Â Â Â Â Â Â Â Â Â Â BenchmarkÂ Â Â Â Â Â Execution Time [ms]Â Â Â Â Â Â # of M&S GCs > > [1]Â Â Â Â Â Â # of newspace GCs [1]Â Â Â Parameters > > BenchmarkXML > > Â Â Â Â Â Â Â Â Â Â Â Â SAX - > > VWÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 93418Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 0Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â > > Â Â Â Â > > Â 2060Â Â Â > > Â Â Â Â Â Â SAX - > > XMLSuiteÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 9921Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 0Â Â Â Â Â Â Â Â Â Â Â Â > > Â Â Â Â > > Â Â Â Â Â Â Â Â 410 Â Â > > > > As you can see, the latter is roughly 10 times faster.Â > > That's the VW parser, which is slower than XMLParser. And again, it > was of DOM parsing. I see. I got confused since VW's parser class is XMLParser... > > > I agree my implementation which uses Expat is clearly suboptimalÂ > > and need to be improved (for example it does not use a ILC-basedÂ > > send to driver so you have a lot of cache misses and does a lotÂ > > of unnecessary memcpy()s, but this can be easily improved) > > Your implementation was fine, and particularly, its XPath/Query was > very impressive. I wasn't attacking you. No worry, I know you were not! Just that I was surprised since my observations - performance wise - were very different. Now I see we were talking about different things.Â > My point was just the hybrid approach built on Expat (which is a non- > validating parser, BTW) should be avoided, in case anyone is > considering it, based on my experience with minidom vs lxml.etree in > Python and with St/X's v2 parser. A parser based on LibXLM2, Xerces, > or something else for SAX, DOM, XPath, etc is probably a better way > of creating an alternative to pure-Smalltalk parsers. I tend to disagree, but I think we have different points of view, that;s why. I have to admit I have not much experience (and need)Â with XML.Â Anyways, I'd like to discuss this more to understand the details. Perhaps privately as it's not strictly Pharo-development related. Best, Jan >Â

July 14, 2016

Re: [Pharo-dev] tricks for XML parsing.

by monty

> Sent: Thursday, July 14, 2016 at 2:50 AM > From: "Jan Vrany" <jan.vrany(a)fit.cvut.cz> > To: pharo-dev(a)lists.pharo.org > Subject: Re: [Pharo-dev] tricks for XML parsing. > > On Thu, 2016-07-14 at 01:58 +0200, monty wrote: > > Thanks for the link. > > > > In-place parsing is a non-starter because it means storing the entire > > input as a string in memory, so you could only parse files that fit > > in Pharo's address space. The multi-gigabyte OpenStreetMap docs the > > article mentions would be unparsable with SAX in a 32-bit VM. > > I do not understand. I only know expat which does - AFAIK - in-place > parsing and surelt does not need the whole input in memory.Â >From the article, footnote 3: "This creates a lifetime dependencyâthe entire source buffer must outlive all document nodes for the technique to work" > > There is always the option of an FFI-based parser, but it shouldn't > > be a hybrid like Python's minidom (FFI Expat with a Python DOM > > implementation), > > because something like that already exists in Smalltalk/X (FFI Expat > > with a Smalltalk DOM) > > I guess you refer to the implementation I did ages ago.Â > > > and it was slower than a St/X port of XMLParser in my tests (I assume > > due to the FFI overhead), so it's probably not worth it. > > Very, very interesting. Where can I find the benchmarks?Â This was well over a year ago, and it was DOM parsing. I was testing if St/X (your branch, I think) could be supported by XMLParser in addition to Pharo, Squeak, and GS, but I ran into too many incompatibilities, like Monticello not working (had to load in .st files), #new not sending #initialize, not being able to modify the value of a dictionary association directly, #lf/#cr weirdness, so I gave up. But not before hacking it enough to kind-of run and compared it with the other parsers. > I just run a very simple benchmark on 112MB document (http://www.xml-be > nchmark.org/downloads.html) and results are quite the opposite:Â > > Benchmark resut: > Generated at :14-07-2016 07:32:25 AM > > Â Â Â Â Â Â Â Â Â Â Â BenchmarkÂ Â Â Â Â Â Execution Time [ms]Â Â Â Â Â Â # of M&S GCs > [1]Â Â Â Â Â Â # of newspace GCs [1]Â Â Â Parameters > BenchmarkXML > Â Â Â Â Â Â Â Â Â Â Â Â SAX - > VWÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 93418Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 0Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â > Â 2060Â Â Â > Â Â Â Â Â Â SAX - > XMLSuiteÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 9921Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â 0Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â > Â Â Â Â Â Â Â Â 410 Â Â > > As you can see, the latter is roughly 10 times faster.Â That's the VW parser, which is slower than XMLParser. And again, it was of DOM parsing. > I agree my implementation which uses Expat is clearly suboptimalÂ > and need to be improved (for example it does not use a ILC-basedÂ > send to driver so you have a lot of cache misses and does a lotÂ > of unnecessary memcpy()s, but this can be easily improved) Your implementation was fine, and particularly, its XPath/Query was very impressive. I wasn't attacking you. My point was just the hybrid approach built on Expat (which is a non-validating parser, BTW) should be avoided, in case anyone is considering it, based on my experience with minidom vs lxml.etree in Python and with St/X's v2 parser. A parser based on LibXLM2, Xerces, or something else for SAX, DOM, XPath, etc is probably a better way of creating an alternative to pure-Smalltalk parsers. > Jan > Â Â > > > But a non-hybrid parser with everything (including the DOM) done in C > > should definitely be faster. > > > > > Sent: Wednesday, July 13, 2016 at 10:27 AM > > > From: stepharo <stepharo(a)free.fr> > > > To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > > > Subject: [Pharo-dev] tricks for XML parsing. > > > > > > Hi guys > > > > > > these free books may be interesting for you > > > > > > Â Â Â Â Â http://aosabook.org/ > > > > > > http://aosabook.org/en/posa/parsing-xml-at-the-speed-of-light.html > > > > > > > > > stef > > > > > > > > > > > > >

July 14, 2016

Re: [Pharo-dev] Download link for latest Pharo6 image on download page

by Dimitris Chloupis

Thank you Marcus, where we can find more info about the Pharo Minimal Image ? On Thu, Jul 14, 2016 at 12:04 PM Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > I have added a link to the download page for Pharo6: > > http://pharo.org/download > > This way it is easier to findâ¦ it is of course in active development, but > quite usable > most of the time. > > Marcus >

July 14, 2016