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

Re: [Pharo-dev] 6.1 Iceberg - how is this supposed to work?

by Todd Blanchard

Yes, trying to install your libclang. Pharo is brand new download of whatever is on the website - 6.1-64 bit version (yes I know its not tested - I was going to test it). OSX Sierra. I have Xcode and all that goes with it installed (my day job is IoT projects with accompanying iPhone apps and occasionally web services development). Homebrew packages installed include... appledoc gmp nettle autoconf gnutls nmap aws-elasticbeanstalk gobject-introspection node awscli graphite2 openssl basset_ios harfbuzz openssl(a)1.1 bazel icu4c p11-kit boot2docker imagemagick pango c-ares jpeg pcre cairo libcroco pixman cmake libffi pkg-config coreutils libgcrypt python cvs libgpg-error python3 dfu-util libpng rbenv docker librsvg readline fontconfig libssh2 redis freetype libtasn1 ruby-build gdbm libtiff sqlite gdk-pixbuf libtool unar geoip libunistring wget gettext libusb wireshark ghostscript little-cms2 xz glib lua > On Nov 10, 2017, at 1:24 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > I would need a way to reproduce this. > > pharo version? (6.1?) > vm version? > operating system? > project you try to install? (I guess is libclang) > > anything I should know about your environment? (image is clean/new? are you behind a proxy? whatever that can help) > > Esteban > >> On 10 Nov 2017, at 00:08, Todd Blanchard <tblanchard(a)mac.com <mailto:tblanchard@mac.com>> wrote: >> >> #(0 25 1) >> >>> On Nov 9, 2017, at 5:45 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>> >>> (LGitLibrary uniqueInstance version) >> >

Nov. 10, 2017

Re: [Pharo-dev] Encoding method source code in Tonel

by Denis Kudriashov

2017-11-10 17:03 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2017-11-10 16:30 GMT+01:00 Martin McClure <martin(a)hand2mouse.com>: >> >> Tonel is intended to be, I believe: >> * For Smalltalk primarily (although there are other languages) >> * Be for any Smalltalk dialect (although the first implementation is for >> Pharo, it is being ported to GemStone, and we intend to port it to VW and >> VA) >> > > Interesting how it will be handled when Pharo will use slots abstraction > exclusively. And more simple, when there will be only package and tags > instead of class categories. > To be more clear. Imaging that instead of #instanceVariables field Pharo will use #slots. And instead of #category it will be #package and #tags > > >> * Be human-readable (some people want to be able to use tools like GitHub >> to look at diffs and such) >> * Be human-editable using normal text editors (important for porting -- >> sometimes you just have to edit the source before it will load, for >> instance) >> >> I think that Tonel using [] to enclose the source is a pretty good idea. >> A proper parser should be able to correctly parse Smalltalk code from any >> dialect, and it makes it human-readable and human-editable. >> >> However, as has been noted in this thread, it would also be nice to >> handle non-Smalltalk code. One way to do this (one that was in an earlier >> proposal but is not currently in Tonel) is to use pure STON for any source >> code that does not have standard Smalltalk syntax. A method like this >> would look something like: >> >> { 'category' : 'public', >> 'source' : 'whatever the source code is, with STON escapes as >> necessary' } >> >> Regards, >> -Martin >> > >

Nov. 10, 2017

Re: [Pharo-dev] Encoding method source code in Tonel

by Denis Kudriashov

2017-11-10 16:30 GMT+01:00 Martin McClure <martin(a)hand2mouse.com>: > > Tonel is intended to be, I believe: > * For Smalltalk primarily (although there are other languages) > * Be for any Smalltalk dialect (although the first implementation is for > Pharo, it is being ported to GemStone, and we intend to port it to VW and > VA) > Interesting how it will be handled when Pharo will use slots abstraction exclusively. And more simple, when there will be only package and tags instead of class categories. > * Be human-readable (some people want to be able to use tools like GitHub > to look at diffs and such) > * Be human-editable using normal text editors (important for porting -- > sometimes you just have to edit the source before it will load, for > instance) > > I think that Tonel using [] to enclose the source is a pretty good idea. A > proper parser should be able to correctly parse Smalltalk code from any > dialect, and it makes it human-readable and human-editable. > > However, as has been noted in this thread, it would also be nice to handle > non-Smalltalk code. One way to do this (one that was in an earlier proposal > but is not currently in Tonel) is to use pure STON for any source code that > does not have standard Smalltalk syntax. A method like this would look > something like: > > { 'category' : 'public', > 'source' : 'whatever the source code is, with STON escapes as > necessary' } > > Regards, > -Martin >

Nov. 10, 2017

[Pharo 7.0-dev] Build #282: 20668-add-breakpoints-menu-to-Nautilus-segment-icons

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

There is a new Pharo build available! The status of the build #282 was: SUCCESS. The Pull Request #463 was integrated: "20668-add-breakpoints-menu-to-Nautilus-segment-icons" Pull request url: https://github.com/pharo-project/pharo/pull/463 Issue Url: https://pharo.fogbugz.com/f/cases/20668 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 10, 2017

Re: [Pharo-dev] Encoding method source code in Tonel

by Martin McClure

On 11/10/2017 07:11 AM, Nicolas Cellier wrote: > The first goals are: > Â - we should prefer a syntax agnostic format for two reasons > Â Â Â * not insulting the future and supporting alternate syntax > extensions (compilerClass) > Â Â Â * making the parsing both robust and efficient (not necessary to > use a RB parser for a quick scan) > Â - we don't want too many decorations that would make the Tonel syntax > look different from Pharo syntax > > If we also want to support human edited Tonel files: > - we want something resilient (not be too much picky about a missing > leading space for example) > - we want the most simple rules and least surprising rules > > The first two goals look really antagonist... > Tonel is intended to be, I believe: * For Smalltalk primarily (although there are other languages) * Be for any Smalltalk dialect (although the first implementation is for Pharo, it is being ported to GemStone, and we intend to port it to VW and VA) * Be human-readable (some people want to be able to use tools like GitHub to look at diffs and such) * Be human-editable using normal text editors (important for porting -- sometimes you just have to edit the source before it will load, for instance) I think that Tonel using [] to enclose the source is a pretty good idea. A proper parser should be able to correctly parse Smalltalk code from any dialect, and it makes it human-readable and human-editable. However, as has been noted in this thread, it would also be nice to handle non-Smalltalk code. One way to do this (one that was in an earlier proposal but is not currently in Tonel) is to use pure STON for any source code that does not have standard Smalltalk syntax.Â A method like this would look something like: { 'category' : 'public', Â Â 'source' : 'whatever the source code is, with STON escapes as necessary' } Regards, -Martin

Nov. 10, 2017

Re: [Pharo-dev] Encoding method source code in Tonel

by Nicolas Cellier

2017-11-10 16:21 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > On 10 Nov 2017, at 16:11, Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com> wrote: > > > > There are other possibilities: if we don't want to change the methodBody > at all, then let's change the opening/closing sequence > > > > - at write, choose a closing sequence that has no exact match in source > code, then use the inverse sequence as the opening sequence > > - at read, just scan for the inverse of opening sequence > > > > opening sequence could be any combination of [{<( > > or maybe just a single [ repeated as many times as necessary > > That is a cool idea (used by some scripting languages, stdin handling, > IIRC). > > Check for conflicts of 1 $] closing sequence for $[ and keep on increasing > the count until there is no conflict. Simple & effective. Supports any > syntax. > > BTW, I held off from commenting about the basic Tonel principle of a > single file, but if 'we want to allow people to edit this file manually' > becomes a goal, then I would be VERY VERY disappointed. > > Sven > > > Bah, pragmatism rules, for patching a typo directly thru github API, it's OK... If it's about replacing IDE with vi, then it's no more Pharo.

Nov. 10, 2017

Re: [Pharo-dev] Encoding method source code in Tonel

by Sven Van Caekenberghe

> On 10 Nov 2017, at 16:11, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > There are other possibilities: if we don't want to change the methodBody at all, then let's change the opening/closing sequence > > - at write, choose a closing sequence that has no exact match in source code, then use the inverse sequence as the opening sequence > - at read, just scan for the inverse of opening sequence > > opening sequence could be any combination of [{<( > or maybe just a single [ repeated as many times as necessary That is a cool idea (used by some scripting languages, stdin handling, IIRC). Check for conflicts of 1 $] closing sequence for $[ and keep on increasing the count until there is no conflict. Simple & effective. Supports any syntax. BTW, I held off from commenting about the basic Tonel principle of a single file, but if 'we want to allow people to edit this file manually' becomes a goal, then I would be VERY VERY disappointed. Sven

Nov. 10, 2017

Re: [Pharo-dev] Encoding method source code in Tonel

by Martin McClure

On 11/10/2017 07:10 AM, Esteban Lorenzano wrote: > Wellâ¦ Iâm working on make it more robust :) > but in general, I disagree with all solutions style âforce some > character to appear in one placeâ. I prefer to rely in a good (better) > parsing than to force such kind of conventions that are also very easy > to break (as soon as people can modify things outside the tools we > propose). > Thanks, Esteban. This is approximately what I was just starting to write. Regards, -Martin

Nov. 10, 2017

Re: [Pharo-dev] Encoding method source code in Tonel

by Nicolas Cellier

2017-11-10 12:08 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > On 10 Nov 2017, at 11:59, Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com> wrote: > > > > My proposition was to force methodBody closing to be on first column, > > and disambiguate potential method conflicts by forcing a more > transparent white space. > > > > Maybe we can force the white space only on conflicting lines that would > begin with a ]. > > Most methods are indented (and even formatted) so the conflict should be > extremely rare. > > It could happen though with multiple line literal string > > > > ^' > > [ > > something went wrong here > > ] > > ' > > > > If first column trick is not acceptable, then we will indeed come up > with more visible escape sequences. > > But don't you think that it would be weird to insert extra whitespace and > not remove it (under the assumption that it does not matter), because is > string constants like in your example, you would actually change code ! > > And yes, we are discussing a very rare case. > > But as you showed, simplifying #methodBody is really important. > > Indeed, in some well known case, a literal would be modified bewteen Pharo and Tonel which would be rare but weird... Currently, Tonel does not have to change the syntax at all. The first goals are: - we should prefer a syntax agnostic format for two reasons * not insulting the future and supporting alternate syntax extensions (compilerClass) * making the parsing both robust and efficient (not necessary to use a RB parser for a quick scan) - we don't want too many decorations that would make the Tonel syntax look different from Pharo syntax If we also want to support human edited Tonel files: - we want something resilient (not be too much picky about a missing leading space for example) - we want the most simple rules and least surprising rules The first two goals look really antagonist... There are other possibilities: if we don't want to change the methodBody at all, then let's change the opening/closing sequence - at write, choose a closing sequence that has no exact match in source code, then use the inverse sequence as the opening sequence - at read, just scan for the inverse of opening sequence opening sequence could be any combination of [{<( or maybe just a single [ repeated as many times as necessary > 2017-11-10 11:49 GMT+01:00 Henrik Sperre Johansen < > henrik.s.johansen(a)veloxit.no>: > > Can a line with a single ] ever at the "right" indentation level? > > Forcing autoformat at commit is a bit heavy hand, but maybe inserting a > tab > > (or 2,3,4 spaces?) would be an ok workaround that doesn't require special > > decoding when loading the code? > > > > Cheers, > > Henry > > > > > > > > -- > > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837. > html > > > > > > >

Nov. 10, 2017

Re: [Pharo-dev] Encoding method source code in Tonel

by Esteban Lorenzano

Wellâ¦ Iâm working on make it more robust :) but in general, I disagree with all solutions style âforce some character to appear in one placeâ. I prefer to rely in a good (better) parsing than to force such kind of conventions that are also very easy to break (as soon as people can modify things outside the tools we propose). Esteban > On 10 Nov 2017, at 08:08, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > >> On 10 Nov 2017, at 11:59, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> My proposition was to force methodBody closing to be on first column, >> and disambiguate potential method conflicts by forcing a more transparent white space. >> >> Maybe we can force the white space only on conflicting lines that would begin with a ]. >> Most methods are indented (and even formatted) so the conflict should be extremely rare. >> It could happen though with multiple line literal string >> >> ^' >> [ >> something went wrong here >> ] >> ' >> >> If first column trick is not acceptable, then we will indeed come up with more visible escape sequences. > > But don't you think that it would be weird to insert extra whitespace and not remove it (under the assumption that it does not matter), because is string constants like in your example, you would actually change code ! > > And yes, we are discussing a very rare case. > > But as you showed, simplifying #methodBody is really important. > >> 2017-11-10 11:49 GMT+01:00 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no>: >> Can a line with a single ] ever at the "right" indentation level? >> Forcing autoformat at commit is a bit heavy hand, but maybe inserting a tab >> (or 2,3,4 spaces?) would be an ok workaround that doesn't require special >> decoding when loading the code? >> >> Cheers, >> Henry >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 10, 2017