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

Advent of code

by Stephane Ducasse

Hi pharoers I would like to know if you would like to participate to http://adventofcode.com/2016 For example we could do the same as https://github.com/norvig/pytudes/blob/master/ipynb/Advent%20of%20Code.ipynb Stef

Nov. 22, 2017

Re: [Pharo-dev] Pharo 6.1 64 bits segmentation fault loading code on Linux

by Thierry Goubier

2017-11-22 13:03 GMT+01:00 Gabriel Cotelli <g.cotelli(a)gmail.com>: > Well that make sense. The problem is that the stable VM is crashing with a > segmentation fault :( on Linux/64 bits. > I can confirm. Given that later vms do not segfault, Eliot told me he prefers to consider the bug(*) solved. Thierry (*) But I have no idea about what the bug is. Running the stable pharo vm under valgrind also triggers the segfault, valgrind complains a lot and signal permamently lost memory, but this is the same with all vms as far as valgrind is concerned (i.e. non-crashing and even non-pharo vms are no better, except that they don't crash). > > On Nov 22, 2017 08:46, "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: > >> >> >> On 21 Nov 2017, at 21:00, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: >> >> I can't find a latest 6.1 vm so I tried with the Pharo 7 Latest VM (wget >> -O- get.pharo.org/64/vmTLatest70 | bash) and the 6.1 image but crashes >> with a segmentation fault also. >> >> >> by concept, there is no âlatest 6.1 vmâ since latest is âunstableâ >> (alpha) and 6.1 is not (or it shouldnât). >> >> latest is always related to the development version. >> >> Esteban >> >> >> On Tue, Nov 21, 2017 at 12:03 PM, Thierry Goubier < >> thierry.goubier(a)gmail.com> wrote: >> >>> Hi Gabriel, >>> >>> I had such segfaults with the stable 6.1/64bits on Linux. I solved them >>> by ensuring the use of a more recent version than the stable one. >>> >>> Thierry >>> >>> >>> 2017-11-21 15:56 GMT+01:00 Gabriel Cotelli <g.cotelli(a)gmail.com>: >>> >>>> I've created the following issue: >>>> >>>> https://pharo.fogbugz.com/f/cases/20737/Segmentation-fault-t >>>> rying-to-load-code-into-a-64-bits-Pharo-6-1-Linux >>>> I can reproduce it easily so if you need some more info let me know. >>>> >>>> Regards, >>>> Gabriel >>>> >>> >>> >> >>

Nov. 22, 2017

Re: [Pharo-dev] Pharo 6.1 64 bits segmentation fault loading code on Linux

by Gabriel Cotelli

Well that make sense. The problem is that the stable VM is crashing with a segmentation fault :( on Linux/64 bits. On Nov 22, 2017 08:46, "Esteban Lorenzano" <estebanlm(a)gmail.com> wrote: > > > On 21 Nov 2017, at 21:00, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > I can't find a latest 6.1 vm so I tried with the Pharo 7 Latest VM (wget > -O- get.pharo.org/64/vmTLatest70 | bash) and the 6.1 image but crashes > with a segmentation fault also. > > > by concept, there is no âlatest 6.1 vmâ since latest is âunstableâ (alpha) > and 6.1 is not (or it shouldnât). > > latest is always related to the development version. > > Esteban > > > On Tue, Nov 21, 2017 at 12:03 PM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> Hi Gabriel, >> >> I had such segfaults with the stable 6.1/64bits on Linux. I solved them >> by ensuring the use of a more recent version than the stable one. >> >> Thierry >> >> >> 2017-11-21 15:56 GMT+01:00 Gabriel Cotelli <g.cotelli(a)gmail.com>: >> >>> I've created the following issue: >>> >>> https://pharo.fogbugz.com/f/cases/20737/Segmentation-fault-t >>> rying-to-load-code-into-a-64-bits-Pharo-6-1-Linux >>> I can reproduce it easily so if you need some more info let me know. >>> >>> Regards, >>> Gabriel >>> >> >> > >

Nov. 22, 2017

Re: [Pharo-dev] Pharo 6.1 64 bits segmentation fault loading code on Linux

by Esteban Lorenzano

> On 21 Nov 2017, at 21:00, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: > > I can't find a latest 6.1 vm so I tried with the Pharo 7 Latest VM (wget -O- get.pharo.org/64/vmTLatest70 <http://get.pharo.org/64/vmTLatest70> | bash) and the 6.1 image but crashes with a segmentation fault also. by concept, there is no âlatest 6.1 vmâ since latest is âunstableâ (alpha) and 6.1 is not (or it shouldnât). latest is always related to the development version. Esteban > > On Tue, Nov 21, 2017 at 12:03 PM, Thierry Goubier <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > Hi Gabriel, > > I had such segfaults with the stable 6.1/64bits on Linux. I solved them by ensuring the use of a more recent version than the stable one. > > Thierry > > > 2017-11-21 15:56 GMT+01:00 Gabriel Cotelli <g.cotelli(a)gmail.com <mailto:g.cotelli@gmail.com>>: > I've created the following issue: > > https://pharo.fogbugz.com/f/cases/20737/Segmentation-fault-trying-to-load-c… <https://pharo.fogbugz.com/f/cases/20737/Segmentation-fault-trying-to-load-c…> > I can reproduce it easily so if you need some more info let me know. > > Regards, > Gabriel > >

Nov. 22, 2017

Re: [Pharo-dev] DateAndTime local time zone not initialised in Pharo 7

by Alistair Grant

Hi Sven, On 22 November 2017 at 11:08, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > In my Pharo 7 images, DateAndTime's local time zone is not initialised. > > Normally, Locale class>>#startUp: calls > > DateAndTime localTimeZone: LocalTimeZone new > > but that was somehow not the case, hence the image operated as in TZ 0, UTC, offset 0. > > Does anyone else see this ? Yes (just noticed after our other discussion about Dates). > It seems Locale is not in the #startupList but it should be. > > Sven +1 Cheers, Alistair

Nov. 22, 2017

DateAndTime local time zone not initialised in Pharo 7

by Sven Van Caekenberghe

In my Pharo 7 images, DateAndTime's local time zone is not initialised. Normally, Locale class>>#startUp: calls DateAndTime localTimeZone: LocalTimeZone new but that was somehow not the case, hence the image operated as in TZ 0, UTC, offset 0. Does anyone else see this ? It seems Locale is not in the #startupList but it should be. Sven

Nov. 22, 2017

Re: [Pharo-dev] Pharo and special unary selectors

by Peter UhnÃ¡k

I just randomly ran into this project https://github.com/ba-st/aconcagua which seems to be designed around such unary selectors. On Sat, Nov 18, 2017 at 12:55 AM, Benoit St-Jean via Pharo-dev < pharo-dev(a)lists.pharo.org> wrote: > > > ---------- Forwarded message ---------- > From: Benoit St-Jean <bstjean(a)yahoo.com> > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Cc: > Bcc: > Date: Fri, 17 Nov 2017 23:55:56 +0000 (UTC) > Subject: Re: [Pharo-dev] Pharo and special unary selectors > Personnally, I against adding those special symbols. They add close to > nothing (except complexity in the parser) to what we can actually do! > > Besides, what does 30$ + 17$ add up to? Oh! Did I tell you it was > actually $30USD + $17CAN ? :) > > > ----------------- > BenoÃ®t St-Jean > Yahoo! Messenger: bstjean > Twitter: @BenLeChialeux > Pinterest: benoitstjean > Instagram: Chef_Benito > IRC: lamneth > Blogue: endormitoire.wordpress.com > "A standpoint is an intellectual horizon of radius zero". (A. Einstein) > > > On Friday, November 17, 2017, 6:41:11 PM EST, Ben Coman < > btc(a)openinworld.com> wrote: > > > If a valid Smalltalk method identifier contains only... > [a-zA-Z][a-zA-Z0-9]* > http://www.osdata.com/programming/firstprograms/valididentifiers.html > > then one option could be that unary symbols must touch the previous > identifier, i.e. no intervening whitespace, > > 100% > 20$ > 40â¬ > 12â° > portion% > someMoney$ > > > or pick a new "unary separator/binder" > > 100'% or 100 '% > 20'$ or 20 '$ > 40'â¬ or 40 'â¬ > 12'â° or 12 'â° > portion'% > someMoney'$ > > > or re-use the existing colon which indicates an argument to the right, > to indicate an argument to the left.... > > 100 :% > 20 :$ > 40 :â¬ > 12 :â° (for promille) > portion :% > someMoney :$ > > which is unambiguous regarding block variable definitions since no > messages are valid in the block variable definition area, > but this may complicate precedence semantics due to its similarity to a > keyword selector, > and would complicate things if the space was missing. > > > > On 18 November 2017 at 04:02, Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com> wrote: > > > > 2017-11-17 18:32 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > > Le 17/11/2017 Ã 10:14, Nicolas Cellier a Ã©crit : > > > > 2017-11-17 17:40 GMT+01:00 Gabriel Cotelli <g.cotelli(a)gmail.com <mailto: > g.cotelli(a)gmail.com>>: > > I would really like to see % removed as a binary selector and > available to use in unary or keyword ones. The only implementor in a > Pharo 6 image is: > > % aNumber > > ^ self \\ aNumber > > > +1, such alias has nothing to do in Kernel > > So it's juts aliasing \\ , and % most widespread usage in the real > world is por percentages (the use in modular arithmetic is more a > programming thing that math notation I think). > > And for allowing more Unicode code points for selector names I'm > totally in for Symbols, Arrows, Math Symbols, etc... We just need to > analyse the ones that makes sense as binary selectors, and the ones > allowed for unary and keyword ones. This will allow us to write > pretty cool DSLs. > > Just my opinion. > > This could also be the case for punctuation like ! and ? > > The idea of Torsten is more generic, any combination of binary char could > be used. > From what I understand from https://en.wikipedia.org/wiki/ LR_parser > <https://en.wikipedia.org/wiki/LR_parser> we would just have to scan one > more token ahead for deciding if unary or binary, and could preserve our > simple shift reduce steps... > > > The Smalltalk parsers being handwritten, there wouldn't be shift/reduces > to contend with, and, anyway, the lexer doesn't shift/reduce; it would > simply creates a token up to the next separator (that is goble up the next > space/cr/end of line dot/closing parenthesis/etc...) > > > I don't have academical cursus, so I may be approximate, but the manually > written parsers just have to read a single token ahead so far, and linearly > build the parseNode, to me it was equivalent. > > > So it seems doable for resolving the send. > > > Sort of. The parser difficulty would be this one: > > anObject % print > > > Yes, that's a severe limitation. Context free => it's a binary... Or we > have to use ( ). > But then it's unfriendly to have different rules for unary symbols versus > unary words... > It devaluates the idea... > > > > Is this a binary selector with a print argument or two unary selectors? > > > Less ambiguous... > anObject'% print > anObject '% print > > > > > Using the symbol table when you parse would solve it, but that is > certainly not context free... > > More problematic would be the declaration of method, if we have both a > unary + and a binary +, we will need new syntax for marking the difference. > > > > In most cases, distinguishing between unary + declaration and binary + > declaration would be doable: > > + whatever > > is the start of a binary selector > > + ^ self > > is the start (or the declaration of) an unary selector. > > But writing > > + self > > Can be interpreted as either unary plus doing self, or binary + method > definition... > > > a "unary binder" could distinguish them... > > binary method definition... > + self > > unary method definition... > '+ self > > > > issues... > > + b | c | > > a binary plus with unused temp and implicit ^self, or unary + with binary > | sent to b with unary (c |) parameter etc... > > > + b | c | > binary plus, unused temporary c > > '+ b | c | > unary plus, first | is binary, second | is unary > or maybe it would need to be... '+ b | c'| > > > > So we need a new syntax meaning that there is no parameter, like + ][ or > anything yet unused... > > > without ' > > + || b | c | > empty local variable definition, next | is binary, second | is unary > > also with local variable... > + | lv1 | b | c | > + | lv1 | b | c'| > > > > > > > Whether it's worth or not is another matter... > > > Well, one should probably try to implement the various parsers for that > (extend RB, extend the SmaCC Smalltalk parser, extend the Petit Parser) to > see how much complexity it would bring. > > Coming up with strange interpretations one could do with that syntax can > be helpfull as well. > > Regards, > > Thierry > > On Fri, Nov 17, 2017 at 6:32 AM, Torsten Bergmann <astares(a)gmx.de > <mailto:astares@gmx.de>> wrote: > > Hi, > > just something to think about: one thing I always liked about > Smalltalk is that it allows for nice DSL's. We have nice things > like a unit framework in Pharo, ... > > In the most simple case one can easily implement own units just > by providing a unary messages: > > 1 m > 1 second > 1 px > 1 EUR > > One can easily implement an own Money class with a currency and > then do polymorphic tricks like > > 10 EUR + 20 EUR > > > btw, did the recently announced QA Release Tests add enforcement all > selectors to start with a lowercase? > I felt that one a bit overly-restrictive, which would break such a > currency DSL. > > cheers -ben > > > > But we can currently can not implement special unary selectors > (including special unary selectors with unicode) like: > > 100 % > 20 $ > 40 â¬ > 12 â° (for promille) > > Especially things like 20 % would be nice for layout issues or > other (Bloc comes to mind). > > Maybe we should put that on the roadmap of Pharo because IMHO it > would be cool to support such things in the > future. Dont know how much effort it currently means on the > technical level but maybe others can comment. > > Thx > T. > > > >

Nov. 22, 2017

[Pharo 7.0-dev] Build #316: 20735-ComposablePresenter-classowneron-is-missing-the-initialization-call

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

There is a new Pharo build available! The status of the build #316 was: SUCCESS. The Pull Request #517 was integrated: "20735-ComposablePresenter-classowneron-is-missing-the-initialization-call" Pull request url: https://github.com/pharo-project/pharo/pull/517 Issue Url: https://pharo.fogbugz.com/f/cases/20735 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 22, 2017

Re: [Pharo-dev] Iceberg operations overview

by Cyril Ferlicot

On Wed, Nov 22, 2017 at 9:33 AM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > during brainstorming of the Iceberg UI simplification we created a document > that shows what the current Iceberg operations do. It should help you to > clarify the role of the working copy etc. > > See the attachment. > Great! Can this be added to Iceberg's README on github? Thanks! > Note: merge uses the reference commit of the loaded version as the base. > > Cheers, > -- Pavel -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Nov. 22, 2017

Re: [Pharo-dev] Iceberg operations overview

by Denis Kudriashov

Very nice. Thank's 2017-11-22 9:33 GMT+01:00 Pavel Krivanek <pavel.krivanek(a)gmail.com>: > Hi, > > during brainstorming of the Iceberg UI simplification we created a > document that shows what the current Iceberg operations do. It should help > you to clarify the role of the working copy etc. > > See the attachment. > > Note: merge uses the reference commit of the loaded version as the base. > > Cheers, > -- Pavel >

Nov. 22, 2017