- Pharo-dev - lists.pharo.org

Encoding method source code in Tonel

by Sven Van Caekenberghe

Hi, Right now, TonelParser>>#methodBody looks a bit dangerous (too complex), and Nicolas already found some breaking cases as well a one possible solution. I was thinking a bit along the same lines, so here is a proposal. Overall I think we should keep the current readability of Tonel as much as possible (it is very important for diffs), while still being correct - i.e. no method source, even convoluted ones, possibly in different languages should break the encoding. The problem is how to quickly scan a stream for the closing $] (which occurs as a single character on a line by its own). Especially in Pharo source code, that situation (a conflict between the proper marker and actual source) is very rare, since code is usually intended. But is can occur and must be dealt with. The proposal is to just double the $] but only on lines that could conflict (which are lines consisting of only $]'s). The code itself becomes quite simple and remains fast enough. Here is some code to play with (EOL fixed to #cr for demo purposes): writer := [ :stream :methodSourceString | stream nextPut: $[; cr. methodSourceString linesDo: [ :line | (line notEmpty and: [ line allSatisfy: [ :ch | ch = $] ] ]) ifTrue: [ stream << $] ]. stream << line; cr ]. stream nextPut: $]; cr ]. reader := [ :stream | | line | (stream peekFor: $[) ifTrue: [ stream nextLine ] ifFalse: [ self error ]. String streamContents: [ :out | [ (line := stream nextLine) = ']' ] whileFalse: [ (line notEmpty and: [ line allSatisfy: [ :ch | ch = $] ] ]) ifTrue: [ out << line allButFirst ] ifFalse: [ out << line ]. out cr ] ] ]. encoded := String streamContents: [ :out | writer value: out value: (Collection>>#inject:into:) sourceCode ]. (reader value: encoded readStream) = ((Collection>>#inject:into:) sourceCode, String cr). escapedEncoded := String streamContents: [ :out | writer value: out value: 'test "Make sure there is no whitespace at line start to force an escape" self isFoo ifTrue: [ #foo ] ifFalse: [ [ "block" #bar ]] ' ]. (reader value: escapedEncoded readStream). What do you think ? Did I miss any special cases ? Is the price (very occasional insertion of an extra #] in the source code) worth the advantage (a simple, safe scheme). Sven PS: Note that several tools line syntax highlighting and double-click next to brackets have problems with weird delimiters such as in the above code ;-)

Nov. 10, 2017

Tonel line end convention

by Sven Van Caekenberghe

Hi, I am wondering if the current approach regarding the Tonel line end convention is a good idea. TonelWriter>>#newLine ^ OSPlatform current lineEnding Although it is no problem to write Pharo code that transparently deals with (accepts) any line end convention, not specifying a fixed line end convention is bound to lead to version control problems, in my opinion. Person 1 on platform A has line end convention #cr. After editing a single method, the .class.st is generated. Now the whole file is using #cr. From the standpoint of the version control system, *every* line is now potentially changed (when the previous line end convention was different). Or am I missing something that mitigates this ? Sven

Nov. 10, 2017

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

by Esteban Lorenzano

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> 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] Metacello we need automated conflict resolution between Baselines and Configurations

by Peter UhnÃ¡k

Hi Dale, I am aware of locking, but that requires I know all the recursive dependencies so I can lock them before loading the project itself. I can do that locally (and I've done it in the past), but I cannot easily force that upon users. This also applies for SmalltalkCI which will just try to load the baseline and will run into the conflict (the conflict pasted in the first mail actually comes from SCI). Thanks, Peter On Thu, Nov 9, 2017 at 11:17 PM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > Peter, > > Metacello locks are supposed to address this kind of problem ... at this > point in time, any project that is loaded from a git project should be > 'locked' using a Metacello lock. > > The lock means that any request to load that project will use the locked > version instead of the version specified in the configuration/baseline. > > A lock can be applied to a project without actually loading the project ... > > Presuming that you have a preference towards using the local git > repository for project X, then you can lock project X with a reference to > the local git repository: > > Metacello new > > project: 'X'; > > repository: '......'; > > lock. > > ... and from this point on any attempt by Metacello to load project X will > load from the local git repository ... > > Once you have a local clone of a project it is very likely that you will > want to share that repository amongst many of your local pharo projects and > to do that with Metacallo you need to lock those projects in each of your > images, including new images ... > > This can lead to a lot of locking ... I talk about the approach that I use > in tODE to address this problem in two Smalltalks talks [1] and [2]... > > Dale > > [1] https://www.youtube.com/watch?v=Ejmqs0xLvSk&list=PLCGAAdUizz > H06AkHg6_UxZ6QZBgz84yAc&index=25 > > [2] https://www.youtube.com/watch?v=QshDlH1ADZQ > > > > On 11/9/17 12:21 PM, Peter UhnÃ¡k wrote: > >> Hi, >> >> as people are increasingly starting to move to git and baselines, it is >> becoming more and more common that there are loading issues: >> >> A depends on B and C >> >> B depends on ConfigurationOfX >> >> C depends on BaselineOfX >> >> and then loading fails on >> >> MetacelloConflictingProjectError: Load Conflict between existing >> BaselineOfStateSpecs [baseline] from github://dionisiydk/StateSpecs:v2.4.x >> and ConfigurationOfStateSpecs stable from http://www.smalltalkhub.com/mc >> /dionisiy/StateSpecs/main >> >> I imagine that this will become more and more common. >> >> Can this be resolved in some automated fashion? >> >> Thanks, >> Peter >> > > >

Nov. 10, 2017

Re: [Pharo-dev] float & fraction equality bug

by Nicolas Cellier

2017-11-10 1:18 GMT+01:00 <raffaello.giulietti(a)lifeware.ch>: > On 2017-11-10 00:02, Henrik Sperre Johansen wrote: > > raffaello.giulietti wrote > >> On 2017-11-09 21:49, Stephane Ducasse wrote: > >>> On Thu, Nov 9, 2017 at 5:34 PM, Nicolas Cellier > >>> < > > > >> nicolas.cellier.aka.nice@ > > > >> > wrote: > >>>> Note that this started a long time ago and comes up episodically > >>>> http://forum.world.st/Fraction-equality-and-Float- > infinity-problem-td48323.html > >>>> http://forum.world.st/BUG-Equality-should-be-transitive- > tc1404335.html > >>>> https://lists.gforge.inria.fr/pipermail/pharo-project/2009- > July/010496.html > >>>> > >>>> A bit like a "marronnier" (in French, a subject that is treated > >>>> periodically > >>>> by newspapers and magazines) > >>> > >>> Hi nicolas except that now we could a chapter describing some of the > >>> answers :) > >>> > >> > >> It's easy to make = behave as an equivalence if the two objects it > >> operates on are of the same class. > >> > >> But it is well-known that it's hard when their classes are different, > >> short of implementing = trivially in this case. > >> > >> This is to say that there's no real hope to make = an equivalence if the > >> wish is to make it useful in the presence of different kind of objects. > >> > >> In the context of numeric computations, luckily, there is some hope when > >> conversions, if possible at all, are all performed consistently. But the > >> same conversions should then be applied for all operations, whether > >> comparisons or subtractions, etc., to ensure more familiar properties. > >> This is not currently the case in Pharo. > >> > >> > >> > >> Raffaello > > > > Personally, I rather like = being transitive across different types of > > objects, which is the case with the current implementation.* > > It would not be if, like you suggest, multiple Fractions = the same > Float. > > Take a moment to also reflect on what it would mean if, as the > implication > > goes, a float represents a range of numbers on the rational number line, > > rather than a single point. > > Taken to its logical conclusion, it follows you'd need to also redefine > the > > other mathematical operators to reflect this, as well as conversion to > exact > > numbers like Integers and Fractions being lossy, rather than the other > way > > around. > > You could certainly build an interesting system of floats with such a > > property (I can swear I've read a paper on one somewhere...), but it > > wouldn't be the world of IEEE754 Floats we live in. > > > > Other properties one might deem beneficial, such as > > a + b > a if b > 0, > > or > > (a + b) + c = a + (b + c) > > are not true in the context of floats. Does that mean we need to fix them > > too? > > My 2c: It feels like you are asking Floats to be something they're not, > and > > the answer simply isn't to try and paint over issues and try and make > them > > look like something they're not. > > > > Cheers, > > Henry > > > > > > Personally, I could live without mixed arithmetic between unlimited and > limited precision numbers: I would always be explicit in the > conversions. They are so different in nature, like apples and oranges are. > > This also entails that I would accept that 1 = 1.0 evaluates to false, > that 1 <= 1.0 throws an exception and all consequences of this. > > But this would be unacceptable for most Smalltalkers for many good > reasons. And, as you point out, = and total ordering are easily > preserved if Floats are converted to Fractions. But then please convert > Floats to Fractions even when adding, multiplying, etc. > > To me a Float does not stand for an interval. It's just a real number > that happens to have strange, unfamiliar operations that resemble the > pure ones. Some familiar properties also hold for these strange > operations, others do not. > > > > It would be tempting, but a priori I don't believe it would be sustainable. What is nice in Smalltalk is that we can just try. (a bit less easy for int+float because it's hardwired in the primitives and maybe the JIT too) So in current Pharo, if I just define Fraction>>adaptToFloat: f andSend: m ^f isFinite ifTrue: [f asFraction perform: m with: self] ifFalse: [f perform: m with: self asFloat] and symmetric in Float>>adaptToFraction: f andSend: m ^self isFinite ifTrue: [f perform: m with: self asFraction] ifFalse: [f asFloat perform: m with: self] then World does not seem to fall apart... We would need to measure if noticeable slow down happens

Nov. 10, 2017

Re: [Pharo-dev] float & fraction equality bug

by Nicolas Cellier

2017-11-10 0:02 GMT+01:00 Henrik Sperre Johansen < henrik.s.johansen(a)veloxit.no>: > raffaello.giulietti wrote > > On 2017-11-09 21:49, Stephane Ducasse wrote: > >> On Thu, Nov 9, 2017 at 5:34 PM, Nicolas Cellier > >> < > > > nicolas.cellier.aka.nice@ > > > > wrote: > >>> Note that this started a long time ago and comes up episodically > >>> http://forum.world.st/Fraction-equality-and-Float-infinity- > problem-td48323.html > >>> http://forum.world.st/BUG-Equality-should-be-transitive-tc1404335.html > >>> https://lists.gforge.inria.fr/pipermail/pharo-project/2009-J > uly/010496.html > >>> > >>> A bit like a "marronnier" (in French, a subject that is treated > >>> periodically > >>> by newspapers and magazines) > >> > >> Hi nicolas except that now we could a chapter describing some of the > >> answers :) > >> > > > > It's easy to make = behave as an equivalence if the two objects it > > operates on are of the same class. > > > > But it is well-known that it's hard when their classes are different, > > short of implementing = trivially in this case. > > > > This is to say that there's no real hope to make = an equivalence if the > > wish is to make it useful in the presence of different kind of objects. > > > > In the context of numeric computations, luckily, there is some hope when > > conversions, if possible at all, are all performed consistently. But the > > same conversions should then be applied for all operations, whether > > comparisons or subtractions, etc., to ensure more familiar properties. > > This is not currently the case in Pharo. > > > > > > > > Raffaello > > Personally, I rather like = being transitive across different types of > objects, which is the case with the current implementation.* > It would not be if, like you suggest, multiple Fractions = the same Float. > Take a moment to also reflect on what it would mean if, as the implication > goes, a float represents a range of numbers on the rational number line, > rather than a single point. > Taken to its logical conclusion, it follows you'd need to also redefine the > other mathematical operators to reflect this, as well as conversion to > exact > numbers like Integers and Fractions being lossy, rather than the other way > around. > You could certainly build an interesting system of floats with such a > property (I can swear I've read a paper on one somewhere...), but it > wouldn't be the world of IEEE754 Floats we live in. > > Other properties one might deem beneficial, such as > a + b > a if b > 0, > or > (a + b) + c = a + (b + c) > are not true in the context of floats. Does that mean we need to fix them > too? > My 2c: It feels like you are asking Floats to be something they're not, and > the answer simply isn't to try and paint over issues and try and make them > look like something they're not. > > Cheers, > Henry > > on the other hand, his original expectations are true when restricted in the world of floating point: (a isFloat & b isFloat & a isFinite & b isFinite) ==> (a-b)=0 = (a=b) so the astonishment is legitimate It's just that we have a more complex model in which above Smalltalk expression cannot hold with mixed arithmetic without breaking higher expectations... > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

Nov. 10, 2017

Re: [Pharo-dev] CRC checks of downloads fail really often

by Marcus Denker

We will see how much it costsâ¦ price is: $0.049 for GB Traffic from US & EUROPE $0.125 / GB From ASIA & PACIFIC $0.185 / GB From LATIN AMERICA (one could turn off the more expensive ones). But the idea is to set this up as an intermediate solution and then work on the main infrastructure (that is, replace files.pharo.org, with either a server or maybe just amazon s3 of the cost with the CDN in front is OK). Marcus > On 9 Nov 2017, at 21:08, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Thanks Marcus. For 200 Euros I can even offering to the community. > I'm sad that our inria infrastructure is not at the right level. > > Stef > > On Thu, Nov 9, 2017 at 7:18 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > As a first step of a new instrastructure I have added a mirror: > > https://mirror.pharo.org > > update is not yet working for files that keep the same name yet change content. > This will be added I hope tomorrow. > > Marcus > >> On 9 Nov 2017, at 18:33, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> Yes, this drives me crazy. You cannot do much or invite people to use it because the download does not work. Sometimes it is really ridiculous. >> >> Norbert >> >>> Am 09.11.2017 um 10:28 schrieb Guillermo Polito <guillermopolito(a)gmail.com>: >>> >>> Hi, >>> >>> In the travis jobs of many projects (pillar, ossubprocess), I see often this failure: >>> >>> image.eqoxhz/Pharo7.0-32bit-b648168.image bad CRC 298b4e64 (should be 85ee6276) >>> >>> This is happening all the time for large builds, generally in 1 out of 4 jobs: >>> >>> https://travis-ci.org/marianopeck/OSSubprocess/builds/299269491 >>> https://travis-ci.org/pillar-markup/pillar/jobs/298538119 >>> >>> Of course restarting the job (to retry the download) solves the problem eventually. >>> >>> Is this because of the inria infrastructure working funny? >>> >>> >>> -- >>> >>> Guille Polito >>> Research Engineer >>> >>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>> CRIStAL - UMR 9189 >>> French National Center for Scientific Research - http://www.cnrs.fr >>> >>> Web: http://guillep.github.io >>> Phone: +33 06 52 70 66 13 >> > >

Nov. 10, 2017

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

by Todd Blanchard

#(0 25 1) > On Nov 9, 2017, at 5:45 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > (LGitLibrary uniqueInstance version)

Nov. 10, 2017

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

by Esteban Lorenzano

whatâs your libgit2 version? (LGitLibrary uniqueInstance version) because is weird you are the only one getting that error. Esteban > On 9 Nov 2017, at 21:10, Todd Blanchard <tblanchard(a)mac.com> wrote: > > Using iceberg tool now I get > > Invalid verion 0 on git_remote_callbacks > >> On Nov 9, 2017, at 2:40 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> oops. >> that was my bad (I put .properties in the wrong place). >> >> please, pull again and retry :) >> >> >>> On 9 Nov 2017, at 18:49, Todd Blanchard <tblanchard(a)mac.com> wrote: >>> >>> I just downloaded the latest Pharo 6.1-64. >>> >>> Now I want to load repository git@github.com:estebanlm/libclang-pharo-bindings.git >>> >>> I have tried.... >>> >>> Opening an iceberg window and clicking +clone and pasting this in there. It fails either with a walkback or vm crash. >>> >>> Also tried >>> >>> Metacello new >>> repository: 'github://estebanlm/libclang-pharo-bindings/src'; (incidentally why are these a different format from what github uses?) >> >> because they are used to indicate repository/subdir/tag/branch, etc. >> but I agree it is far from perfect. >> >> Esteban >> >>> baseline: 'LibClang'; >>> load. >>> >>> Walkback with 'Could not resolve BaselineOfLibClang' >>> >>> Not having much fun here. I definitely do not understand the new code management tools. >>> >>> -Todd Blanchard >> >> > >

Nov. 10, 2017

Re: [Pharo-dev] float & fraction equality bug

by raffaello.giulietti＠lifeware.ch

On 2017-11-10 00:02, Henrik Sperre Johansen wrote: > raffaello.giulietti wrote >> On 2017-11-09 21:49, Stephane Ducasse wrote: >>> On Thu, Nov 9, 2017 at 5:34 PM, Nicolas Cellier >>> < > >> nicolas.cellier.aka.nice@ > >> > wrote: >>>> Note that this started a long time ago and comes up episodically >>>> http://forum.world.st/Fraction-equality-and-Float-infinity-problem-td48323.… >>>> http://forum.world.st/BUG-Equality-should-be-transitive-tc1404335.html >>>> https://lists.gforge.inria.fr/pipermail/pharo-project/2009-July/010496.html >>>> >>>> A bit like a "marronnier" (in French, a subject that is treated >>>> periodically >>>> by newspapers and magazines) >>> >>> Hi nicolas except that now we could a chapter describing some of the >>> answers :) >>> >> >> It's easy to make = behave as an equivalence if the two objects it >> operates on are of the same class. >> >> But it is well-known that it's hard when their classes are different, >> short of implementing = trivially in this case. >> >> This is to say that there's no real hope to make = an equivalence if the >> wish is to make it useful in the presence of different kind of objects. >> >> In the context of numeric computations, luckily, there is some hope when >> conversions, if possible at all, are all performed consistently. But the >> same conversions should then be applied for all operations, whether >> comparisons or subtractions, etc., to ensure more familiar properties. >> This is not currently the case in Pharo. >> >> >> >> Raffaello > > Personally, I rather like = being transitive across different types of > objects, which is the case with the current implementation.* > It would not be if, like you suggest, multiple Fractions = the same Float. > Take a moment to also reflect on what it would mean if, as the implication > goes, a float represents a range of numbers on the rational number line, > rather than a single point. > Taken to its logical conclusion, it follows you'd need to also redefine the > other mathematical operators to reflect this, as well as conversion to exact > numbers like Integers and Fractions being lossy, rather than the other way > around. > You could certainly build an interesting system of floats with such a > property (I can swear I've read a paper on one somewhere...), but it > wouldn't be the world of IEEE754 Floats we live in. > > Other properties one might deem beneficial, such as > a + b > a if b > 0, > or > (a + b) + c = a + (b + c) > are not true in the context of floats. Does that mean we need to fix them > too? > My 2c: It feels like you are asking Floats to be something they're not, and > the answer simply isn't to try and paint over issues and try and make them > look like something they're not. > > Cheers, > Henry > > Personally, I could live without mixed arithmetic between unlimited and limited precision numbers: I would always be explicit in the conversions. They are so different in nature, like apples and oranges are. This also entails that I would accept that 1 = 1.0 evaluates to false, that 1 <= 1.0 throws an exception and all consequences of this. But this would be unacceptable for most Smalltalkers for many good reasons. And, as you point out, = and total ordering are easily preserved if Floats are converted to Fractions. But then please convert Floats to Fractions even when adding, multiplying, etc. To me a Float does not stand for an interval. It's just a real number that happens to have strange, unfamiliar operations that resemble the pure ones. Some familiar properties also hold for these strange operations, others do not.

Nov. 10, 2017