September 2017 - Pharo-dev - lists.pharo.org

Updating CI plugins

by Guillermo Polito

Hi all, I'm updating several CI plugins related to Multibranch builds. Since Jenkins is moving fast is this direction, it is healthy that we follow updates regularly. You'll see the exact list of plugins and versions installed in here: https://pharo.fogbugz.com/f/cases/20402/Update-CI-Plugins -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Sept. 10, 2017

Re: [Pharo-dev] poor state of fuel

by Norbert Hartl

Max, Just an update. Martin commited a new package that solves the encoding/decoding of SmallInteger and Character. Together with the patch from nicolas my dumps work again Norbert > Am 29.08.2017 um 21:42 schrieb Max Leske <maxleske(a)gmail.com>: > > Thanks Tim. > > Norbert, I just saw that I have already created an issue for the 64-bit problems. I donât know whether tackling that will help you though. In any case, Iâll see that we try to work on those problems. > > I canât give you an exact timeline because I will be on holiday but I guess I can make an integration by around mid September. > > Cheers, > Max > > > >> On 29 August 2017 at 16:09:06, Tim Mackinnon (tim(a)testit.works) wrote: >> >> As a small data point, a fuel file written out on AWS Lambda Linux (not sure what version - I think it's an ubuntu, but they don't really say), is readable on OS X 64bit . >> >> So it seems like you must have found something unusual. >> >> Tim >> >> Sent from my iPhone >> >> On 29 Aug 2017, at 11:13, Max Leske <maxleske(a)gmail.com> wrote: >> >>> Hi Norbert, >>> >>> We still maintain Fuel. >>> >>> I was not aware of the problem you describe. Could you open an issue on github (https://github.com/theseion/Fuel/issues) with a detailed explanation and, if possible, steps to reproduce the problem? >>> >>> Cheers, >>> Max >>> >>>> On 29 August 2017 at 11:04:34, Norbert Hartl (norbert(a)hartl.name) wrote: >>>> >>>> I'm migrating most of my projects to pharo 6.1 at the moment. I come from pharo 4, I skipped pharo 5. I use 64 bit which removes a lot of stuff that does not need to be installed and makes deployment better. That really feels much better. >>>> >>>> I use jenkins and there if a test fails a fuel dump is written to disk. The jenkins server is ubuntu linux with the vm of the opensuse build. My laptop has Mac OS and cannot read back those fuel dumps. I use the same image version on jenkins and my laptop. Both are 64bit. >>>> >>>> I asked that on discord and there was a mentioning that not only the 64 bit fuel has problems. So I wanted to ask what is the state of fuel right now. I consider fuel one of the core technologies in pharo and it is sad if it just stops working. >>>> >>>> Any feedback is highly appreciated, >>>> >>>> Norbert >>>>

Sept. 10, 2017

Re: [Pharo-dev] About Git support for windows

by Norbert Hartl

Hi! > Am 10.09.2017 um 05:44 schrieb Alexandre Bergel <alexandre.bergel(a)me.com>: > > Hi! > > I live very very much this idea! > > I am wondering why do we need the timestamp? Git knows about who has committed each line and by whom. Why should we have some redundant information? > the difference is commit time vs. compile time. From a collaboration point of view it is the important time. From a personal view it might do a service to have the date you compiled. But putting the timestamp where git will resolve a conflict is a no-go. Everyone who used filetree with metadata can tell it is super annoying and destroys the complete experience. Norbert > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On Sep 9, 2017, at 6:39 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> >>> On 8 Sep 2017, at 22:02, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> >>> Hi All, >>> >>>> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>>> >>>> Hi all >>>> >>>> At ESUG we discussed with Esteban, martin mcClure, Dale and (many many >>>> others :), esteban designed a nice class file format. So that we will >>>> not have 2Gb of space on harddisc, problems with long method names and >>>> sluggish commits. >>> >>> Wow, that's great news! It'll make it much easier to import from Pharo hit repositories. Thank you, Esteban! >>> >>> Can someone post the grammar or a description of the syntax asap? >> >> I will commit it with a spec next week. >> and I made the parser by hand and simple enough (e.g. I didnât use RBParser) so it can be ported easily to other dialects. >> >> Esteban >> >>> >>>> >>>> He is waiting at Wien and is probably checking everything right now. >>>> >>>> It is a nice format because we will be able to use it to communicate >>>> by emails using it. So readable, compact and I like it :) >>> >>> Lovely! Details please :-) >>> >>>> >>>> Stef >>>> >>> >> >>

Sept. 10, 2017

Re: [Pharo-dev] Bloc Shock

by Tudor Girba

:) > On Sep 9, 2017, at 7:30 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > I was playing with Bloc when I came across the following: > <http://forum.world.st/file/t128965/Screenshot_2017-08-31_14.jpeg> > > I am taken aback by the elegance and utility of this widget, and also aware > of all the countless steps we took to have it appear there - Bloc, GT, etc, > etc. It feels like proof of the synergy of moving one step forward every > day. Thanks to all. > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > -- www.tudorgirba.com www.feenk.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

Sept. 10, 2017

Re: [Pharo-dev] About Git support for windows

by Alexandre Bergel

Hi! I live very very much this idea! I am wondering why do we need the timestamp? Git knows about who has committed each line and by whom. Why should we have some redundant information? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Sep 9, 2017, at 6:39 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 8 Sep 2017, at 22:02, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi All, >> >>> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>> >>> Hi all >>> >>> At ESUG we discussed with Esteban, martin mcClure, Dale and (many many >>> others :), esteban designed a nice class file format. So that we will >>> not have 2Gb of space on harddisc, problems with long method names and >>> sluggish commits. >> >> Wow, that's great news! It'll make it much easier to import from Pharo hit repositories. Thank you, Esteban! >> >> Can someone post the grammar or a description of the syntax asap? > > I will commit it with a spec next week. > and I made the parser by hand and simple enough (e.g. I didnât use RBParser) so it can be ported easily to other dialects. > > Esteban > >> >>> >>> He is waiting at Wien and is probably checking everything right now. >>> >>> It is a nice format because we will be able to use it to communicate >>> by emails using it. So readable, compact and I like it :) >> >> Lovely! Details please :-) >> >>> >>> Stef >>> >> > >

Sept. 10, 2017

Pending FileSystem PRs (was: [Pharo-users] Pharo 6 FileSystem>>changeDirectory: is missing)

by Alistair Grant

Hi Stef, (I've moved this to pharo-dev) On Sat, Sep 09, 2017 at 11:09:55AM +0200, Stephane Ducasse wrote: > Alistair > > did I miss some pending PR to be integrated for FS? I'm not aware of any pending PRs at the moment. The issues that are still open are: - Default Working Directory https://pharo.fogbugz.com/f/cases/5723/ Waiting on FFI to be added to the kernel. Do you know what the status of that is? There's also been a request to extend the PR to allow the directory to be changed. Hopefully Rajula can add this. - https://pharo.fogbugz.com/f/cases/20294/Add-FileAttributesPlugin-to-the-lin… Eliot kindly made lots of recommendations on how to improve the VM plugin which I've done and sent back to Eliot. - https://pharo.fogbugz.com/f/cases/19609/FileReference-base-should-be-before… It is probably worthwhile you taking a look at this one. The closed list is: - https://pharo.fogbugz.com/f/cases/13217/FS-basename-with-compound-path-stri… - https://pharo.fogbugz.com/f/cases/18042 - https://pharo.fogbugz.com/f/cases/20165/Support-segment-path-printing - https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile - https://pharo.fogbugz.com/f/cases/20307/File-names-should-not-be-canonicali… - https://pharo.fogbugz.com/f/cases/20189/FileReference-considers-same-file-d… - https://pharo.fogbugz.com/f/cases/20164/Caching-DiskStore-defaultWorkingDir… Of course, there may be others that I haven't seen. > I'm getting back to reality after a totally fun and intense ESUG conference. > Stef Feeling extremely envious - I wasn't able to make it this year... Cheers, Alistair

Sept. 9, 2017

Re: [Pharo-dev] About Git support for windows

by Peter UhnÃ¡k

> > I don't think it's even a problem > I do remember that I hated long classes because of git conflicts, but I suppose if we have good tooling for that it shouldn't be such a pain. Git can sometimes make the diff really weirdly... Peter

Sept. 9, 2017

Re: [Pharo-dev] About Git support for windows

by Eliot Miranda

Hi Esteban, > On Sep 9, 2017, at 8:04 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > >> On 9 Sep 2017, at 12:28, Henrik Nergaard <draagren(a)outlook.com> wrote: >> >> >> but this is still WIP: for example timestamp needs to go to avoid conflicts. >> why/how would this cause conflicts versus other changes? > > two people modifying same method could have a marge without conflict, but if both modify same line (like the timestamp line), then for sure it will be a conflict :) I think this is a serious mistake. Time stamps and author marks are important (even more important if the unit of commit is a single file for the whole class). I'm always irritated when Monticello commits carelessly edit a method back instead of reverting, hence lost my the original time stamp. I want to know who edited a method when so I can ask them for help. I don't want to see spurious changes. So making if a conflict and preserving time stamps remains important to me. > > Esteban > >> >> >> Fra: Pharo-dev <pharo-dev-bounces(a)lists.pharo.org> pÃ¥ vegne av Esteban Lorenzano <estebanlm(a)gmail.com> >> Sendt: 9. september 2017 11:39:12 >> Til: Pharo Development List >> Emne: Re: [Pharo-dev] About Git support for windows >> >> >> > On 8 Sep 2017, at 22:02, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> > >> > Hi All, >> > >> >> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> >> >> Hi all >> >> >> >> At ESUG we discussed with Esteban, martin mcClure, Dale and (many many >> >> others :), esteban designed a nice class file format. So that we will >> >> not have 2Gb of space on harddisc, problems with long method names and >> >> sluggish commits. >> > >> > Wow, that's great news! It'll make it much easier to import from Pharo hit repositories. Thank you, Esteban! >> > >> > Can someone post the grammar or a description of the syntax asap? >> >> I will commit it with a spec next week. >> and I made the parser by hand and simple enough (e.g. I didnât use RBParser) so it can be ported easily to other dialects. >> >> Esteban >> >> > >> >> >> >> He is waiting at Wien and is probably checking everything right now. >> >> >> >> It is a nice format because we will be able to use it to communicate >> >> by emails using it. So readable, compact and I like it :) >> > >> > Lovely! Details please :-) >> > >> >> >> >> Stef >> >> >> > >

Sept. 9, 2017

Re: [Pharo-dev] About Git support for windows

by Eliot Miranda

Hi Esteban, > On Sep 8, 2017, at 7:08 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > >> On 8 Sep 2017, at 22:35, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: >> >> for example here >> >> https://github.com/estebanlm/pharo-tonel/blob/master/src/Morphic-Core/Morph… >> > but this is still WIP: for example timestamp needs to go to avoid conflicts. If there is still time to change the syntax slightly I would get rid of the white space around the method source so instead of Point class >> x: anInt1 y: anInt2 [ ^ self new setX: anInt1 Y: anInt2 ] specify it must be Point class >> x: anInt1 y: anInt2 [ ^ self new setX: anInt1 Y: anInt2] because trailing white space will only accumulate, something I see in Pharo and Squeak code. Alternatively have the output add white space if required and the input remove any and all trailing white space. > >> and it also shows one downside --- up until now we didn't care much about how many methods are in class (because it was just another file), but now we have 10000 lines of code class. > > I do not think this is a huge problem since the format is not intended to be for direct edition, but yes, this is a downside... no format will be perfect. I don't think it's even a problem. It's a benefit.. It's /much/ more convenient to be able to edit a single file than edit many different files if editing is required. We already know the advantage it has in getting selectors out of file names :-) The main issue with a file containing many methods is method order stability. So sort by alphabetical order of method selector, not by protocol. > > Esteban > >> >> >> >>> On Fri, Sep 8, 2017 at 10:25 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>> From memory one class of class/trait and one for extension >>> >>> In class/Trait >>> >>> "class / trait comments >>> >>> >>> comment" >>> >>> Special STON order for classes to minimic our logical order (ie >>> package tag add the end). >>> >>> Class { >>> >>> } >>> >>> or >>> >>> Trait { >>> name: #T >>> } >>> >>> + >>> >>> Point class >> x: anInt1 y: anInt2 >>> [ >>> ^ self new setX: anInt1 Y: anInt2 >>> ] >>> >>> >>> + >>> >>> STON for meta data >>> >>> {category : "printing"} >>> >>> >>> Since I do not know STON all the above can be wrong but this is the idea. >>> >>> >>> Stef >>> >>> >>> On Fri, Sep 8, 2017 at 10:02 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> > Hi All, >>> > >>> >> On Sep 8, 2017, at 9:44 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>> >> >>> >> Hi all >>> >> >>> >> At ESUG we discussed with Esteban, martin mcClure, Dale and (many many >>> >> others :), esteban designed a nice class file format. So that we will >>> >> not have 2Gb of space on harddisc, problems with long method names and >>> >> sluggish commits. >>> > >>> > Wow, that's great news! It'll make it much easier to import from Pharo hit repositories. Thank you, Esteban! >>> > >>> > Can someone post the grammar or a description of the syntax asap? >>> > >>> >> >>> >> He is waiting at Wien and is probably checking everything right now. >>> >> >>> >> It is a nice format because we will be able to use it to communicate >>> >> by emails using it. So readable, compact and I like it :) >>> > >>> > Lovely! Details please :-) >>> > >>> >> >>> >> Stef >>> >> >>> > >>> >>

Sept. 9, 2017

Bloc Shock

by Sean P. DeNigris

I was playing with Bloc when I came across the following: <http://forum.world.st/file/t128965/Screenshot_2017-08-31_14.jpeg> I am taken aback by the elegance and utility of this widget, and also aware of all the countless steps we took to have it appear there - Bloc, GT, etc, etc. It feels like proof of the synergy of moving one step forward every day. Thanks to all. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Sept. 9, 2017