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

Re: [Pharo-dev] Building the VM on Windows - weird git message

by Esteban Lorenzano

mmmm... bad. but you should be ok, we do not build the genie plugin at the moment :) Esteban On Mon, Nov 18, 2013 at 11:23 PM, phil(a)highoctane.be <phil(a)highoctane.be>wrote: > I am trying to get the VM to build on Windows 8, following the procedure > outlined on https://github.com/pharo-project/pharo-vm > > When doing a git clone, I do get the following: > > > Philippe@gravitation7 ~ > $ git clone --depth=1 https://github.com/pharo-project/pharo-vm.git > Cloning into 'pharo-vm'... > remote: Counting objects: 17493, done. > remote: Compressing objects: 100% (12363/12363), done. > remote: Total 17493 (delta 4271), reused 17137 (delta 4143) > Receiving objects: 100% (17493/17493), 19.28 MiB | 1.88 MiB/s, done. > Resolving deltas: 100% (4271/4271), done. > Checking connectivity... done > *error: unable to create file > mc/VMMaker-oscog.package/GeniePlugin.class/instance* > > */primSameClassAbsoluteStrokeDistanceMyPoints.otherPoints.myVectors.otherVectors.* > > *mySquaredLengths.otherSquaredLengths.myAngles.otherAngles.maxSizeAndReferenceFla* > *g.rowBase.rowInsertRemove.rowInsertRemoveCount..st (Filename too long)* > Checking out files: 100% (17525/17525), done. > fatal: unable to checkout working tree > warning: Clone succeeded, but checkout failed. > You can inspect what was checked out with 'git status' > and retry the checkout with 'git checkout -f HEAD' > > Pretty weird error I'd say. > > Anyone knowing what this is related to? > > Phil > >

Nov. 18, 2013

Building the VM on Windows - weird git message

by phil＠highoctane.be

I am trying to get the VM to build on Windows 8, following the procedure outlined on https://github.com/pharo-project/pharo-vm When doing a git clone, I do get the following: Philippe@gravitation7 ~ $ git clone --depth=1 https://github.com/pharo-project/pharo-vm.git Cloning into 'pharo-vm'... remote: Counting objects: 17493, done. remote: Compressing objects: 100% (12363/12363), done. remote: Total 17493 (delta 4271), reused 17137 (delta 4143) Receiving objects: 100% (17493/17493), 19.28 MiB | 1.88 MiB/s, done. Resolving deltas: 100% (4271/4271), done. Checking connectivity... done *error: unable to create file mc/VMMaker-oscog.package/GeniePlugin.class/instance* */primSameClassAbsoluteStrokeDistanceMyPoints.otherPoints.myVectors.otherVectors.* *mySquaredLengths.otherSquaredLengths.myAngles.otherAngles.maxSizeAndReferenceFla* *g.rowBase.rowInsertRemove.rowInsertRemoveCount..st (Filename too long)* Checking out files: 100% (17525/17525), done. fatal: unable to checkout working tree warning: Clone succeeded, but checkout failed. You can inspect what was checked out with 'git status' and retry the checkout with 'git checkout -f HEAD' Pretty weird error I'd say. Anyone knowing what this is related to? Phil

Nov. 18, 2013

Re: [Pharo-dev] Xtreams in Pharo 3

by Nicolas Cellier

The tests pass with this hack PEGInfinity>>adaptToInteger: anInteger andCompare: selector "This makes optimized inlining of timesRepeat: work." ^#( < <= ~= ) includes: selector But then they take 10 times longer than Squeak thanks to timesRepeat: inlining "optimization". Maybe timesRepeat: inlining should be restricted to the case when receiver is an integer literal... Or just removed. 2013/11/18 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Ah, NotFoundError is also undeclared in Squeak, it is the VisualWorks > class name. > It could go into Xtreams-Support... > > For PEG parsing test, I think you are right, this is timesRepeat: > They passed in Squeak last time I tried. > But these are advanced features not required for legacy Stream replacement. > > > 2013/11/18 Esteban A. Maringolo <emaringolo(a)gmail.com> > > One more reason to look after Pharo 3 :) >> Esteban A. Maringolo >> >> >> 2013/11/18 Sven Van Caekenberghe <sven(a)stfx.eu>: >> > Hi, >> > >> > This evening I tried to load Nicolas Cellierâs Xtreams ( >> http://www.squeaksource.com/Xtreams/) into Pharo #30582. This went >> almost flawless ! >> > >> > I went for >> > >> > ConfigurationOfXtreams project bleedingEdge load. >> > >> > which loaded >> > >> > a MetacelloFetchingMCSpecLoader(linear load : >> > linear load : 1.3-baseline [ConfigurationOfXtreams] >> > load : Xtreams-Support-nice.11 >> > load : Xtreams-Core-nice.20 >> > load : Xtreams-Terminals-nice.31 >> > load : Xtreams-Transforms-nice.23 >> > load : Xtreams-Substreams-nice.19 >> > load : Xtreams-CoreTests-nice.20 >> > load : Xtreams-TerminalsTests-nice.17 >> > load : Xtreams-TransformsTests-nice.14 >> > load : Xtreams-SubstreamsTests-nice.13 >> > load : Xtreams-Parsing-cwp.6 >> > load : Xtreams-ParsingTests-cwp.5 >> > load : Xtreams-TerminalsFileSystem-nice.3 >> > load : Xtreams-TerminalsFileSystemTests-nice.2) >> > >> > There is one Undeclared in XTReadStream>>#detect: (NotFoundError should >> be NotFound in Pharo). >> > >> > Unit tests passed, except for the PEGParser related ones, most probably >> because Opal optimises #timesRepeat: which is overridden in PEGInfinity, I >> am not sure how this should be fixed, maybe with an Opal compiler directive >> somewhere ? >> > >> > Running the tests resulted in some external semaphore warnings in the >> Transcript. >> > >> > I also loaded Nicolasâ new #legacy layer >> (Xtreams-LegacyStreamAPI-nice.1), Iâll have to study that, it sure looks >> interesting. >> > >> > In any case: great work, thanks Nicolas ! >> > >> > Sven >> > >> > >> >> >

Nov. 18, 2013

Re: [Pharo-dev] Xtreams in Pharo 3

by Nicolas Cellier

Ah, NotFoundError is also undeclared in Squeak, it is the VisualWorks class name. It could go into Xtreams-Support... For PEG parsing test, I think you are right, this is timesRepeat: They passed in Squeak last time I tried. But these are advanced features not required for legacy Stream replacement. 2013/11/18 Esteban A. Maringolo <emaringolo(a)gmail.com> > One more reason to look after Pharo 3 :) > Esteban A. Maringolo > > > 2013/11/18 Sven Van Caekenberghe <sven(a)stfx.eu>: > > Hi, > > > > This evening I tried to load Nicolas Cellierâs Xtreams ( > http://www.squeaksource.com/Xtreams/) into Pharo #30582. This went almost > flawless ! > > > > I went for > > > > ConfigurationOfXtreams project bleedingEdge load. > > > > which loaded > > > > a MetacelloFetchingMCSpecLoader(linear load : > > linear load : 1.3-baseline [ConfigurationOfXtreams] > > load : Xtreams-Support-nice.11 > > load : Xtreams-Core-nice.20 > > load : Xtreams-Terminals-nice.31 > > load : Xtreams-Transforms-nice.23 > > load : Xtreams-Substreams-nice.19 > > load : Xtreams-CoreTests-nice.20 > > load : Xtreams-TerminalsTests-nice.17 > > load : Xtreams-TransformsTests-nice.14 > > load : Xtreams-SubstreamsTests-nice.13 > > load : Xtreams-Parsing-cwp.6 > > load : Xtreams-ParsingTests-cwp.5 > > load : Xtreams-TerminalsFileSystem-nice.3 > > load : Xtreams-TerminalsFileSystemTests-nice.2) > > > > There is one Undeclared in XTReadStream>>#detect: (NotFoundError should > be NotFound in Pharo). > > > > Unit tests passed, except for the PEGParser related ones, most probably > because Opal optimises #timesRepeat: which is overridden in PEGInfinity, I > am not sure how this should be fixed, maybe with an Opal compiler directive > somewhere ? > > > > Running the tests resulted in some external semaphore warnings in the > Transcript. > > > > I also loaded Nicolasâ new #legacy layer > (Xtreams-LegacyStreamAPI-nice.1), Iâll have to study that, it sure looks > interesting. > > > > In any case: great work, thanks Nicolas ! > > > > Sven > > > > > >

Nov. 18, 2013

Re: [Pharo-dev] [Moose-dev] SVG described countries in Roassal

by Alexandre Bergel

> What do you mean? Athens is in Pharo 3.0 by default. We are no longer loading it manually. You can safely invest all your energy in Athens :). :-) I will Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 18, 2013

Re: [Pharo-dev] [Moose-dev] SVG described countries in Roassal

by Tudor Girba

Hi, On Mon, Nov 18, 2013 at 9:44 PM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > Hi Stef, > > Your email made me think a lot. > > > But in roassal you do not have the concept of a polylines? > > Actually no, but it is likely that we should. A general way to defines > polygons is the way to go. > > > I do not get why you want to pollute Roassal with SVG names. > > If you introduce the notion of Path why don;t you do it independent of > SVG > > because SVG is one way to represent path. > > After having played with Athens, I understand better what you actually > mean. > Indeed, the end user should work with a notion of polygon in general, and > not with SVG. > > > Because I think that as a user I do not want to if my code works on svg > or another external format. > > > >> It follows the same pattern no? > > > > Yes but this is different because ROBox is a roassal box not an svg or > another format. > > If tomorrow you get a pdf reader and access a library of pdf library. Do > you want your reader to > > have ROPDFBox? > > > > in SVG you also have > > > > â¢ Rectangle <rect> > > â¢ Circle <circle> > > â¢ Ellipse <ellipse> > > â¢ Line <line> > > â¢ Polyline <polyline> > > â¢ Polygon <polygon> > > â¢ Path <path> > > So I imagine (and hope) that you will not introduce ROSVGRectangle > ROSVGLine > > ROSVGCircle? > > > > So why introducing ROSVGPath > > You are very very right. We indeed do not want to introduce all these > classes. > > Your email made me think about something: rewriting Roassal from scratch, > but putting the core notions brought by Athens at the center of Roassal. I > spend some time on getting the camera working in Roassal, but Athens was > not ready yet. More Roassal will use Athens, and more we are taking > advantages of the graphic card. > This would be so great. > Also, do we have to wait for the text editor to include Athens in Pharo? > The text editor is essentially to bootstrap and remove Morphic right? But > until then, Athens could be part of Pharo. I am now using the Moose image, > which is nicely packaged with proper fonts and Athens. Since there are many > users of Roassal on Morphic, it is hard for me to move to 100% Athens. > What do you mean? Athens is in Pharo 3.0 by default. We are no longer loading it manually. You can safely invest all your energy in Athens :). Doru > Thanks again for your email > > Alexandre > > > > > > > > Stef > >> > >> Alexandre > >> > >> > >> On Nov 17, 2013, at 8:45 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> > >>> I see that you have a loooot of fun. > >>> Now I have the impression that in the future version you should not > expose ROSVGPath and others > >>> because there are at the importer level not Roassal. So why do you > need to wrap them. > >>> If there is something missing in SVGPath what is it? > >>> > >>> Stef > >>> > >>>> Hi! > >>>> > >>>> I had fun understanding how countries may be described using SVG. > >>>> Here is a first shoot: > >>>> > >>>> <Screen Shot 2013-11-16 at 5.36.21 PM.png> > >>>> > >>>> Moving the mouse above a country name highlight the country. You can > now rehearse your geography. > >>>> > >>>> The complete source code of this example is: > >>>> > >>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > >>>> | view element nameComponent label | > >>>> view := ROView new. > >>>> > >>>> ROSVGPath countries do: [ :k | > >>>> element := (ROSVGPath path: (ROSVGPath perform: k)) elementOn: k. > >>>> view add: element. > >>>> ]. > >>>> > >>>> nameComponent := ROElement new. > >>>> ROSVGPath countries do: [ :k | > >>>> label := ROLabel elementOn: k asString. > >>>> label @ ROLightlyHighlightable. > >>>> label on: ROMouseEnter do: [ :event | ROBlink highlight: (view > elementFromModel: event model asSymbol) ]. > >>>> label on: ROMouseLeave do: [ :event | ROBlink unhighlight: (view > elementFromModel: event model asSymbol) ]. > >>>> nameComponent add: label. > >>>> ]. > >>>> ROGridLayout new > >>>> gapSize: -3; > >>>> lineItemsCount: 15; > >>>> on: nameComponent elements. > >>>> > >>>> view add: nameComponent. > >>>> nameComponent translateTo: 0 @ 400. > >>>> > >>>> view openInWindowSized: 1000 @ 700 > >>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > >>>> > >>>> Cheers, > >>>> Alexandre > >>>> -- > >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>>> Alexandre Bergel http://www.bergel.eu > >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>>> > >>>> > >>>> > >>> > >> > >> -- > >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >> Alexandre Bergel http://www.bergel.eu > >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >> > >> > >> > >> > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 18, 2013

Re: [Pharo-dev] Xtreams in Pharo 3

by Esteban A. Maringolo

One more reason to look after Pharo 3 :) Esteban A. Maringolo 2013/11/18 Sven Van Caekenberghe <sven(a)stfx.eu>: > Hi, > > This evening I tried to load Nicolas Cellierâs Xtreams (http://www.squeaksource.com/Xtreams/) into Pharo #30582. This went almost flawless ! > > I went for > > ConfigurationOfXtreams project bleedingEdge load. > > which loaded > > a MetacelloFetchingMCSpecLoader(linear load : > linear load : 1.3-baseline [ConfigurationOfXtreams] > load : Xtreams-Support-nice.11 > load : Xtreams-Core-nice.20 > load : Xtreams-Terminals-nice.31 > load : Xtreams-Transforms-nice.23 > load : Xtreams-Substreams-nice.19 > load : Xtreams-CoreTests-nice.20 > load : Xtreams-TerminalsTests-nice.17 > load : Xtreams-TransformsTests-nice.14 > load : Xtreams-SubstreamsTests-nice.13 > load : Xtreams-Parsing-cwp.6 > load : Xtreams-ParsingTests-cwp.5 > load : Xtreams-TerminalsFileSystem-nice.3 > load : Xtreams-TerminalsFileSystemTests-nice.2) > > There is one Undeclared in XTReadStream>>#detect: (NotFoundError should be NotFound in Pharo). > > Unit tests passed, except for the PEGParser related ones, most probably because Opal optimises #timesRepeat: which is overridden in PEGInfinity, I am not sure how this should be fixed, maybe with an Opal compiler directive somewhere ? > > Running the tests resulted in some external semaphore warnings in the Transcript. > > I also loaded Nicolasâ new #legacy layer (Xtreams-LegacyStreamAPI-nice.1), Iâll have to study that, it sure looks interesting. > > In any case: great work, thanks Nicolas ! > > Sven > >

Nov. 18, 2013

Xtreams in Pharo 3

by Sven Van Caekenberghe

Hi, This evening I tried to load Nicolas Cellierâs Xtreams (http://www.squeaksource.com/Xtreams/) into Pharo #30582. This went almost flawless ! I went for ConfigurationOfXtreams project bleedingEdge load. which loaded a MetacelloFetchingMCSpecLoader(linear load : linear load : 1.3-baseline [ConfigurationOfXtreams] load : Xtreams-Support-nice.11 load : Xtreams-Core-nice.20 load : Xtreams-Terminals-nice.31 load : Xtreams-Transforms-nice.23 load : Xtreams-Substreams-nice.19 load : Xtreams-CoreTests-nice.20 load : Xtreams-TerminalsTests-nice.17 load : Xtreams-TransformsTests-nice.14 load : Xtreams-SubstreamsTests-nice.13 load : Xtreams-Parsing-cwp.6 load : Xtreams-ParsingTests-cwp.5 load : Xtreams-TerminalsFileSystem-nice.3 load : Xtreams-TerminalsFileSystemTests-nice.2) There is one Undeclared in XTReadStream>>#detect: (NotFoundError should be NotFound in Pharo). Unit tests passed, except for the PEGParser related ones, most probably because Opal optimises #timesRepeat: which is overridden in PEGInfinity, I am not sure how this should be fixed, maybe with an Opal compiler directive somewhere ? Running the tests resulted in some external semaphore warnings in the Transcript. I also loaded Nicolasâ new #legacy layer (Xtreams-LegacyStreamAPI-nice.1), Iâll have to study that, it sure looks interesting. In any case: great work, thanks Nicolas ! Sven

Nov. 18, 2013

Re: [Pharo-dev] [Moose-dev] SVG described countries in Roassal

by Alexandre Bergel

Hi Stef, Your email made me think a lot. > But in roassal you do not have the concept of a polylines? Actually no, but it is likely that we should. A general way to defines polygons is the way to go. > I do not get why you want to pollute Roassal with SVG names. > If you introduce the notion of Path why don;t you do it independent of SVG > because SVG is one way to represent path. After having played with Athens, I understand better what you actually mean. Indeed, the end user should work with a notion of polygon in general, and not with SVG. > Because I think that as a user I do not want to if my code works on svg or another external format. > >> It follows the same pattern no? > > Yes but this is different because ROBox is a roassal box not an svg or another format. > If tomorrow you get a pdf reader and access a library of pdf library. Do you want your reader to > have ROPDFBox? > > in SVG you also have > > â¢ Rectangle <rect> > â¢ Circle <circle> > â¢ Ellipse <ellipse> > â¢ Line <line> > â¢ Polyline <polyline> > â¢ Polygon <polygon> > â¢ Path <path> > So I imagine (and hope) that you will not introduce ROSVGRectangle ROSVGLine > ROSVGCircle? > > So why introducing ROSVGPath You are very very right. We indeed do not want to introduce all these classes. Your email made me think about something: rewriting Roassal from scratch, but putting the core notions brought by Athens at the center of Roassal. I spend some time on getting the camera working in Roassal, but Athens was not ready yet. More Roassal will use Athens, and more we are taking advantages of the graphic card. Also, do we have to wait for the text editor to include Athens in Pharo? The text editor is essentially to bootstrap and remove Morphic right? But until then, Athens could be part of Pharo. I am now using the Moose image, which is nicely packaged with proper fonts and Athens. Since there are many users of Roassal on Morphic, it is hard for me to move to 100% Athens. Thanks again for your email Alexandre > > > Stef >> >> Alexandre >> >> >> On Nov 17, 2013, at 8:45 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >>> I see that you have a loooot of fun. >>> Now I have the impression that in the future version you should not expose ROSVGPath and others >>> because there are at the importer level not Roassal. So why do you need to wrap them. >>> If there is something missing in SVGPath what is it? >>> >>> Stef >>> >>>> Hi! >>>> >>>> I had fun understanding how countries may be described using SVG. >>>> Here is a first shoot: >>>> >>>> <Screen Shot 2013-11-16 at 5.36.21 PM.png> >>>> >>>> Moving the mouse above a country name highlight the country. You can now rehearse your geography. >>>> >>>> The complete source code of this example is: >>>> >>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>>> | view element nameComponent label | >>>> view := ROView new. >>>> >>>> ROSVGPath countries do: [ :k | >>>> element := (ROSVGPath path: (ROSVGPath perform: k)) elementOn: k. >>>> view add: element. >>>> ]. >>>> >>>> nameComponent := ROElement new. >>>> ROSVGPath countries do: [ :k | >>>> label := ROLabel elementOn: k asString. >>>> label @ ROLightlyHighlightable. >>>> label on: ROMouseEnter do: [ :event | ROBlink highlight: (view elementFromModel: event model asSymbol) ]. >>>> label on: ROMouseLeave do: [ :event | ROBlink unhighlight: (view elementFromModel: event model asSymbol) ]. >>>> nameComponent add: label. >>>> ]. >>>> ROGridLayout new >>>> gapSize: -3; >>>> lineItemsCount: 15; >>>> on: nameComponent elements. >>>> >>>> view add: nameComponent. >>>> nameComponent translateTo: 0 @ 400. >>>> >>>> view openInWindowSized: 1000 @ 700 >>>> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >>>> >>>> Cheers, >>>> Alexandre >>>> -- >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >>>> Alexandre Bergel http://www.bergel.eu >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >>>> >>>> >>>> >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 18, 2013

long double & NativeBoost

by phil＠highoctane.be

How can I use long doubles with NativeBoost? For improved calculations, as we do not have such things in the image it seems. (I may be 100% wrong here but it seems our floats are 32 bit). TIA Phil

Nov. 18, 2013