February 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Differences Compiler vs. OpalCompiler (or parser)

by Eliot Miranda

On Tue, Feb 23, 2016 at 2:26 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > 2016-02-23 18:58 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > >> Hi Nicolai, >> >> On Tue, Feb 23, 2016 at 7:37 AM, Nicolai Hess <nicolaihess(a)gmail.com> >> wrote: >> >>> >>> >>> 2015-11-20 22:57 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >>> >>>> Hi Nicolai, >>>> >>>> On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <nicolaihess(a)gmail.com> >>>> wrote: >>>> >>>>> GTDummyExamples class >>>>> d: anInteger >>>>> <gtExample> >>>>> <label: 'Dummy #d:, depends #c:'> >>>>> <description: 'should raise an exception as the argument is not >>>>> anInteger'> >>>>> <depends: #c:> >>>>> <raises: Literal constant expected -> MessageNotUnderstood> >>>>> >>>>> ^ 1 + anInteger >>>>> >>>>> The old Parser complains about the class name "MessageNotUnderstood" >>>>> used as a pragma >>>>> argument without being a string or symbol >>>>> >>>>> Opal does not complain >>>>> >>>>> Is Opals behavior intended ? >>>>> >>>> >>>> IMO no. The pragma design is that the only valid syntax is of a >>>> message pattern with only literal arguments except for the one piece of >>>> syntactic sugar where the error temporary name in a primitive call with an >>>> error can be given as an identifier, e.g. >>>> >>> >>> But this means smalltalks scanner and parser needs some very special >>> handling just for this pragma. >>> >> >> It turns out to be not that bad. because all the pragmas with error >> codes are associated with methods that have primitives (either a numbered >> primitive or a named primitive from a plaugin) the parser has to handle >> them specially anyway. So here's what the code looks like in Squeak's >> compiler: >> >> Parser class>>primitivePragmaSelectors >> "Answer the selectors of pragmas that specify VM primitives. >> Needed for compile and decomple." >> ^#(primitive: >> primitive:error: >> primitive:error:module: >> primitive:module: >> primitive:module:error:) >> >> and then for each of those there's a method such as >> >> Parser>>primitive: aNameString module: aModuleStringOrNil error: >> errorCodeVariableOrNil >> "Create named primitive with optional error code." >> (aNameString isString and: [ aModuleStringOrNil isNil or: [ >> aModuleStringOrNil isString ] ]) >> ifFalse: [ ^ self expected: 'Named primitive' ]. >> self allocateLiteral: (Array >> with: (aModuleStringOrNil isNil >> ifFalse: [ aModuleStringOrNil asSymbol ]) >> with: aNameString asSymbol >> with: 0 with: 0). >> errorCodeVariableOrNil ifNotNil: >> [encoder floatTemp: (encoder bindTemp: errorCodeVariableOrNil) nowHasDef]. >> ^117 >> >> that answers the number of the primitive for the method. So there are >> three methods that contain "errorCodeVariableOrNil ifNotNil: [encoder >> floatTemp: (encoder bindTemp: errorCodeVariableOrNil) nowHasDef]" to >> declare the error temp. I think that's acceptable. What do you think? >> > > Hi Eliot, > Yes, thats fine, but this part of the parser is independent from how we > use the pragma > > For > <primitive:'func' module:'lib' error:#errorCode> > or > <primitive:'func' module:'lib' error:errorCode> > or > <primitive:'func' module:'lib' error:'errorCode'> > > the code generation is always the same. > But for getting > > <primitive:'func' module:'lib' error:errorCode> > > as valid code, we have to use another special code in > Parser>>#pragmaLiteral: selectorSoFar > > "This nicety allows one to supply a primitive error > temp as a variable name, rather than a string." > ((selectorSoFar beginsWith: 'primitive:') > and: [(selectorSoFar endsWith: 'error:') > and: [hereType == #word]]) ifTrue: > [^self advance]. > > without this extra check, > > <primitive:'func' module:'lib' error:errorCode> > > would raise an error > 'Literal constant expected' > Yes, good point. > > In pharo, opal compilers parser accepts both, errorCode without quote or # > and class names. > > <primitive:'func' module:'lib' error:errorCode> - valid > <someotherpragma keyword:Point> - valid too > If I change opals parser to not allow the second pragma, I need some > special handlign > for the primitive:module:error: pragma - I don't like this. > > Is there any difference between > <primitive:'func' module:'lib' error:errorCode> > and > <primitive:'func' module:'lib' error:'errorCode'> > both will generate the same code, right? > Right, they produce the same code. > > > >> >>> Scanner and/or parser explicit check for the name >>> <primitive: ....> >>> of the pragma of this error var. >>> >> >> Right, which is why it is simple to handle. >> >> >>>> addressField >>>> <primitive: 'primAddressField' module: 'IA32ABI' error: errorCode> >>>> ^self primitiveFailed >>>> >>>> instead of >>>> >>>> addressField >>>> <primitive: 'primAddressField' module: 'IA32ABI' error: 'errorCode'> >>>> ^self primitiveFailed >>>> >>>> >>>> The issues are class reference, class redefinition, class removal etc. >>>> I guess we could extend the pragma syntax to allow class references but >>>> there's a lot of impact. I would prefer if we keep things restricted. >>>> There's nothing to stop one using a symbol and mapping it to a class name, >>>> e.g. >>>> >>>> >>>> GTDummyExamples class >>>> d: anInteger >>>> <gtExample> >>>> <label: 'Dummy #d:, depends #c:'> >>>> <description: 'should raise an exception as the argument is not >>>> anInteger'> >>>> <depends: #c:> >>>> <raises: #MessageNotUnderstood> >>>> >>>> ^ 1 + anInteger >>>> >>>> Also, I *hate* this style of pragma. Why not >>>> >>>> GTDummyExamples class >>>> d: anInteger >>>> <gtExampleLabel: 'Dummy #d:, depends #c:' >>>> description: 'should raise an exception as the argument is not >>>> anInteger' >>>> depends: #c: >>>> raises: #MessageNotUnderstood> >>>> >>>> ^ 1 + anInteger >>>> >>>> ? >>>> >>>> That's how the system is designed to be used. Then the message can be >>>> implemented by a builder which performs the selector from a visitor. >>>> >>>> From squeaks bugtracker : http://bugs.squeak.org/view.php?id=7770 >>>>> >>>>> Cascading message sends to super. >>>>> >>>>> Compiler refuses to compile >>>>> super >>>>> initialize; >>>>> setListProperties >>>>> >>>>> >>>>> It looks like Opal would compile this to >>>>> >>>>> super initialize. >>>>> super setListProperties. >>>>> >>>>> Intended ? Do we want to keep it? >>>>> >>>>> NBNativeCodeGen >>>>> parseOptions: optionsArray >>>>> uses association symbol -> block instead of block -> block >>>>> for caseOf arguments. >>>>> The old parser does not accept this. >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> _,,,^..^,,,_ >>>> best, Eliot >>>> >>> >>> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot >> > > -- _,,,^..^,,,_ best, Eliot

Feb. 24, 2016

Re: [Pharo-dev] Hackathon IoT. I used Pharo.

by phil＠highoctane.be

Very cool. I am downloading the OPC test software. Yeah MODBUS is in the picture (as are a ton of other data source). Thx for the info! Depending on serendipitous conditions, I'll be able to land a prototyping contract and Pharo would be a good thing to use, even if it has to do some OSProcess calls to speed things up development time wise. Philippe On Wed, Feb 24, 2016 at 1:06 AM, Ben Coman <btc(a)openinworld.com> wrote: > On Tue, Feb 23, 2016 at 7:32 PM, philippe.back(a)highoctane.be > <philippe.back(a)gmail.com> wrote: > > FWIW I'll be looking at an industrial bigdata project starting next week. > > This is solid stuff and I'll be a recommender for some things. > > And btw, there is always the old warhorse "Modbus" that *everything* > understands because its such a simple protocol. One problem with > industrial environments is often dealing with a lot of equipment 20+ > years old equipment. I'm keen one day to write a Modbus client for > Pharo. > > If you want to get a feel for OPC technology, one leading vendor > Matrikon provide some tutorials and free simulation software[1] you > can practice on. There are some open source Python clients you can > connect to that server that helps to clarify the essentials and > feasibility for a Pharo connection. > > > Maybe should we focus on the data feeding side of things. > > How fast can we be? > > I don't understand the context of the question. Happy to advise > off-list on any domain specific queries to help Pharo get a leg up. > cheers -ben > https://au.linkedin.com/in/bencoman > > [1] https://www.matrikonopc.com/downloads/178/index.aspx > > > > > Phil > > > > On Feb 23, 2016 11:07 AM, "Ben Coman" <btc(a)openinworld.com> wrote: > >> > >> There is real business opportunity for "Industrial" Internet of > >> Things. Morphic (and next Block) makes Pharo would make a fantastic > >> platform for the HMI (Human Machine Intereface) of a factory or > >> machine. And its good reoccurring work, as engineers are *paid* to > >> consult on troubleshooting, optimising and modifying the factory > >> automation code as factories evolve over time. > >> > >> Two significant enabling technologies are... > >> > >> OPC (Open Platform Computing) - This is *the* integration protocol for > >> factories. Its the most widely adopted interoperability standard for > >> secure, reliable and platform-independent information exchange for > >> industrial automation. > >> > >> * Over 500 OPC Foundation members and thousands of OPC-compliant > >> products > >> https://opcfoundation.org/members > >> > >> * Understanding OPC: Open Connectivity via Open Standards > >> > >> > http://www.automation.com/pdf_articles/Understanding_OPC_Kepware_eBook.pdf > >> > >> EtherCAT - Ethernet for Control Automation Technology adds real-time > >> and other capabilities to classic Ethernet > >> > >> * Endorsed by more than 3,000 companies > >> https://www.ethercat.org/en/members.php > >> > >> * What are the advantages of EtherCAT over other fieldbus technologies? > >> https://www.youtube.com/watch?v=j3j6segCpEc > >> > >> * High speed servo control of motors over EtherCAT - simply not > >> possible with any other industrial comms protocol > >> https://www.youtube.com/watch?v=CXb_m8p3Yt4 > >> > >> * MCUs and EtherCAT Gear Up for the Industrial Internet of Things. > >> > >> > http://www.digikey.com/en/articles/techzone/2015/aug/mcus-and-ethercat-gear… > >> > >> * The *biggest* advantages is the use of standard ethernet, doing > >> away with proprietary hardware and consequent vendor lock in. > >> https://www.youtube.com/watch?v=klxwX_44DcM (stop watching a 5:00) > >> > >> > >> And now these two technology groups are now working together... > >> > >> > https://opcfoundation.org/news/press-releases/opc-foundation-ethercat-techn… > >> > >> > >> cheers -ben > >> > >> > >> > >> On Tue, Feb 23, 2016 at 3:30 PM, stepharo <stepharo(a)free.fr> wrote: > >> > I'm interested too because we Rmod wants to check Pharo as a IoT > >> > platform in > >> > the future > >> > > >> > Le 22/2/16 15:07, philippe.back(a)highoctane.be a Ã©crit : > >> > > >> > LoRa stuff with sensors etc. Integrated REST apis for that in Pharo. > >> > > >> > I'll do a writeup on my blog. > >> > > >> > Lots of opportunities for Pharo in that space. > >> > > >> > Phil > >> > > >> > On Feb 22, 2016 2:49 PM, "Serge Stinckwich" < > serge.stinckwich(a)gmail.com> > >> > wrote: > >> >> > >> >> Great ! What did you exactly, I'm interested by details ;-) > >> >> > >> >> 2016-02-22 14:42 GMT+01:00 phil(a)highoctane.be <phil(a)highoctane.be>: > >> >> > > >> >> > > >> >> > > http://geeko.lesoir.be/2016/02/22/hackapost-un-hackathon-sur-les-applis-iot… > >> >> > >> >> > >> >> > >> >> -- > >> >> Serge Stinckwich > >> >> UCBN & UMI UMMISCO 209 (IRD/UPMC) > >> >> Every DSL ends up being Smalltalk > >> >> http://www.doesnotunderstand.org/ > >> >> > >> > > >> > > > >

Feb. 24, 2016

New Cog VMs available

by Eliot Miranda

...at http://www.mirandabanda.org/files/Cog/VM/VM.r3630 a.k.a. http://www.mirandabanda.org/files/Cog/VM/latest. Noe tat there is a JIT bug in the 64-bit VMs which I shall look at this week. CogVM binaries as per VMMaker.oscog-eem.1697/r3630 General: Fix serious bug in jitted perform: primitive. Thanks to Stephane Ducasse for finding and to Levente Uzoni for diagnosing the bug. If the argument count is one greater than the max number of register arguments (2 in Spur, hence perform:with:with:) then the code to remove the receiver and arguments from the stack neglects to remove the receiver and selector. Spur: Fix bug in markAndTraceWeaklingsFrom:. Fields of weaklings may be immediate so must use followOopField:ofObject: not followObjField:ofObject:. Fix https://pharo.fogbugz.com/f/cases/17536/VM-Crash-when-adding-an-iVar-to-a-s… . When weaklings (and when ephemerons) are scan-marked forwarders must be coped with. 64-bit VMs: Fix a bug in printHex: for 64-bits (faulty arithmetic). ThreadedFFIPlugin: Fix the remaining 64-bit issues in the ThreadedFFIPlugin. The X64SysVFFIPlugin now passes the test suite. Hence include the FFI plugin in 64-bit VMs. Mac VMs: Have the Mac OS X build install Localizable.strings. Add versions for Newspeak, Pharo and Squeak. Rename the key to SelectImagePanePrompt. Temporarily disable the Serial plugin in the Pharo Mac VM until we can track down the relevant platforms/iOS support for the Pharo extensions. Fix argument access on the iOS platform (Mac OS VMs). _,,,^..^,,,_ best, Eliot

Feb. 24, 2016

Re: [Pharo-dev] Hackathon IoT. I used Pharo.

by Ben Coman

On Tue, Feb 23, 2016 at 7:32 PM, philippe.back(a)highoctane.be <philippe.back(a)gmail.com> wrote: > FWIW I'll be looking at an industrial bigdata project starting next week. > This is solid stuff and I'll be a recommender for some things. And btw, there is always the old warhorse "Modbus" that *everything* understands because its such a simple protocol. One problem with industrial environments is often dealing with a lot of equipment 20+ years old equipment. I'm keen one day to write a Modbus client for Pharo. If you want to get a feel for OPC technology, one leading vendor Matrikon provide some tutorials and free simulation software[1] you can practice on. There are some open source Python clients you can connect to that server that helps to clarify the essentials and feasibility for a Pharo connection. > Maybe should we focus on the data feeding side of things. > How fast can we be? I don't understand the context of the question. Happy to advise off-list on any domain specific queries to help Pharo get a leg up. cheers -ben https://au.linkedin.com/in/bencoman [1] https://www.matrikonopc.com/downloads/178/index.aspx > > Phil > > On Feb 23, 2016 11:07 AM, "Ben Coman" <btc(a)openinworld.com> wrote: >> >> There is real business opportunity for "Industrial" Internet of >> Things. Morphic (and next Block) makes Pharo would make a fantastic >> platform for the HMI (Human Machine Intereface) of a factory or >> machine. And its good reoccurring work, as engineers are *paid* to >> consult on troubleshooting, optimising and modifying the factory >> automation code as factories evolve over time. >> >> Two significant enabling technologies are... >> >> OPC (Open Platform Computing) - This is *the* integration protocol for >> factories. Its the most widely adopted interoperability standard for >> secure, reliable and platform-independent information exchange for >> industrial automation. >> >> * Over 500 OPC Foundation members and thousands of OPC-compliant >> products >> https://opcfoundation.org/members >> >> * Understanding OPC: Open Connectivity via Open Standards >> >> http://www.automation.com/pdf_articles/Understanding_OPC_Kepware_eBook.pdf >> >> EtherCAT - Ethernet for Control Automation Technology adds real-time >> and other capabilities to classic Ethernet >> >> * Endorsed by more than 3,000 companies >> https://www.ethercat.org/en/members.php >> >> * What are the advantages of EtherCAT over other fieldbus technologies? >> https://www.youtube.com/watch?v=j3j6segCpEc >> >> * High speed servo control of motors over EtherCAT - simply not >> possible with any other industrial comms protocol >> https://www.youtube.com/watch?v=CXb_m8p3Yt4 >> >> * MCUs and EtherCAT Gear Up for the Industrial Internet of Things. >> >> http://www.digikey.com/en/articles/techzone/2015/aug/mcus-and-ethercat-gear… >> >> * The *biggest* advantages is the use of standard ethernet, doing >> away with proprietary hardware and consequent vendor lock in. >> https://www.youtube.com/watch?v=klxwX_44DcM (stop watching a 5:00) >> >> >> And now these two technology groups are now working together... >> >> https://opcfoundation.org/news/press-releases/opc-foundation-ethercat-techn… >> >> >> cheers -ben >> >> >> >> On Tue, Feb 23, 2016 at 3:30 PM, stepharo <stepharo(a)free.fr> wrote: >> > I'm interested too because we Rmod wants to check Pharo as a IoT >> > platform in >> > the future >> > >> > Le 22/2/16 15:07, philippe.back(a)highoctane.be a Ã©crit : >> > >> > LoRa stuff with sensors etc. Integrated REST apis for that in Pharo. >> > >> > I'll do a writeup on my blog. >> > >> > Lots of opportunities for Pharo in that space. >> > >> > Phil >> > >> > On Feb 22, 2016 2:49 PM, "Serge Stinckwich" <serge.stinckwich(a)gmail.com> >> > wrote: >> >> >> >> Great ! What did you exactly, I'm interested by details ;-) >> >> >> >> 2016-02-22 14:42 GMT+01:00 phil(a)highoctane.be <phil(a)highoctane.be>: >> >> > >> >> > >> >> > http://geeko.lesoir.be/2016/02/22/hackapost-un-hackathon-sur-les-applis-iot… >> >> >> >> >> >> >> >> -- >> >> Serge Stinckwich >> >> UCBN & UMI UMMISCO 209 (IRD/UPMC) >> >> Every DSL ends up being Smalltalk >> >> http://www.doesnotunderstand.org/ >> >> >> > >> >

Feb. 24, 2016

Re: [Pharo-dev] Problem loading new class comments

by Nicolai Hess

2016-02-20 9:54 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr>: > > On 19 Feb 2016, at 22:19, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > On 19 Feb 2016, at 22:06, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2016-02-19 15:37 GMT+01:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > I am working on https://pharo.fogbugz.com/f/cases/16893/Update-STON and I > noticed that class comments did not update, even if they are changed. > > Specifically, the class comments of ConfigurationOfSton and STONWriter did > definitively change, I can see the changed comments in the MC code browser, > but when I load the code, the comments stay the same, both in Nautilus as > using the #comment message. > > #50591 > > !!!!! > There are two changes in the behavior how packages are loaded - somewhere, > don't know what exactly. > See my analysis > 17655 Changes in package loading behavior > I don't know how many changed class comments got lost since Pharo-50497 ! > > > Thanks for looking into this, Nicolai. > > This strikes me as an important bug, not because I reported it, but > because we silently lose code. And because we have to test to guard us > against such loss of functionality. > > > Yes, it seems that for Spur, some code in the class builder was reverted. > (e.g. all the code related to migrating classes with Slots) > > So yes, we have to merge the changes back. > > Marcus > > Please, someone else who can try to reproduce the first error described in 17655 <https://pharo.fogbugz.com/f/cases/17655/Changes-in-package-loading-behavior> Changes in package loading behavior bold vs. normal emphasis for the first package

Feb. 23, 2016

Re: [Pharo-dev] Differences Compiler vs. OpalCompiler (or parser)

by Nicolai Hess

2016-02-23 18:58 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Nicolai, > > On Tue, Feb 23, 2016 at 7:37 AM, Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >> >> >> 2015-11-20 22:57 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >>> Hi Nicolai, >>> >>> On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess <nicolaihess(a)gmail.com> >>> wrote: >>> >>>> GTDummyExamples class >>>> d: anInteger >>>> <gtExample> >>>> <label: 'Dummy #d:, depends #c:'> >>>> <description: 'should raise an exception as the argument is not >>>> anInteger'> >>>> <depends: #c:> >>>> <raises: Literal constant expected -> MessageNotUnderstood> >>>> >>>> ^ 1 + anInteger >>>> >>>> The old Parser complains about the class name "MessageNotUnderstood" >>>> used as a pragma >>>> argument without being a string or symbol >>>> >>>> Opal does not complain >>>> >>>> Is Opals behavior intended ? >>>> >>> >>> IMO no. The pragma design is that the only valid syntax is of a message >>> pattern with only literal arguments except for the one piece of syntactic >>> sugar where the error temporary name in a primitive call with an error can >>> be given as an identifier, e.g. >>> >> >> But this means smalltalks scanner and parser needs some very special >> handling just for this pragma. >> > > It turns out to be not that bad. because all the pragmas with error codes > are associated with methods that have primitives (either a numbered > primitive or a named primitive from a plaugin) the parser has to handle > them specially anyway. So here's what the code looks like in Squeak's > compiler: > > Parser class>>primitivePragmaSelectors > "Answer the selectors of pragmas that specify VM primitives. > Needed for compile and decomple." > ^#(primitive: > primitive:error: > primitive:error:module: > primitive:module: > primitive:module:error:) > > and then for each of those there's a method such as > > Parser>>primitive: aNameString module: aModuleStringOrNil error: > errorCodeVariableOrNil > "Create named primitive with optional error code." > (aNameString isString and: [ aModuleStringOrNil isNil or: [ > aModuleStringOrNil isString ] ]) > ifFalse: [ ^ self expected: 'Named primitive' ]. > self allocateLiteral: (Array > with: (aModuleStringOrNil isNil > ifFalse: [ aModuleStringOrNil asSymbol ]) > with: aNameString asSymbol > with: 0 with: 0). > errorCodeVariableOrNil ifNotNil: > [encoder floatTemp: (encoder bindTemp: errorCodeVariableOrNil) nowHasDef]. > ^117 > > that answers the number of the primitive for the method. So there are > three methods that contain "errorCodeVariableOrNil ifNotNil: [encoder > floatTemp: (encoder bindTemp: errorCodeVariableOrNil) nowHasDef]" to > declare the error temp. I think that's acceptable. What do you think? > Hi Eliot, Yes, thats fine, but this part of the parser is independent from how we use the pragma For <primitive:'func' module:'lib' error:#errorCode> or <primitive:'func' module:'lib' error:errorCode> or <primitive:'func' module:'lib' error:'errorCode'> the code generation is always the same. But for getting <primitive:'func' module:'lib' error:errorCode> as valid code, we have to use another special code in Parser>>#pragmaLiteral: selectorSoFar "This nicety allows one to supply a primitive error temp as a variable name, rather than a string." ((selectorSoFar beginsWith: 'primitive:') and: [(selectorSoFar endsWith: 'error:') and: [hereType == #word]]) ifTrue: [^self advance]. without this extra check, <primitive:'func' module:'lib' error:errorCode> would raise an error 'Literal constant expected' In pharo, opal compilers parser accepts both, errorCode without quote or # and class names. <primitive:'func' module:'lib' error:errorCode> - valid <someotherpragma keyword:Point> - valid too If I change opals parser to not allow the second pragma, I need some special handlign for the primitive:module:error: pragma - I don't like this. Is there any difference between <primitive:'func' module:'lib' error:errorCode> and <primitive:'func' module:'lib' error:'errorCode'> both will generate the same code, right? > >> Scanner and/or parser explicit check for the name >> <primitive: ....> >> of the pragma of this error var. >> > > Right, which is why it is simple to handle. > > >>> addressField >>> <primitive: 'primAddressField' module: 'IA32ABI' error: errorCode> >>> ^self primitiveFailed >>> >>> instead of >>> >>> addressField >>> <primitive: 'primAddressField' module: 'IA32ABI' error: 'errorCode'> >>> ^self primitiveFailed >>> >>> >>> The issues are class reference, class redefinition, class removal etc. >>> I guess we could extend the pragma syntax to allow class references but >>> there's a lot of impact. I would prefer if we keep things restricted. >>> There's nothing to stop one using a symbol and mapping it to a class name, >>> e.g. >>> >>> >>> GTDummyExamples class >>> d: anInteger >>> <gtExample> >>> <label: 'Dummy #d:, depends #c:'> >>> <description: 'should raise an exception as the argument is not >>> anInteger'> >>> <depends: #c:> >>> <raises: #MessageNotUnderstood> >>> >>> ^ 1 + anInteger >>> >>> Also, I *hate* this style of pragma. Why not >>> >>> GTDummyExamples class >>> d: anInteger >>> <gtExampleLabel: 'Dummy #d:, depends #c:' >>> description: 'should raise an exception as the argument is not >>> anInteger' >>> depends: #c: >>> raises: #MessageNotUnderstood> >>> >>> ^ 1 + anInteger >>> >>> ? >>> >>> That's how the system is designed to be used. Then the message can be >>> implemented by a builder which performs the selector from a visitor. >>> >>> From squeaks bugtracker : http://bugs.squeak.org/view.php?id=7770 >>>> >>>> Cascading message sends to super. >>>> >>>> Compiler refuses to compile >>>> super >>>> initialize; >>>> setListProperties >>>> >>>> >>>> It looks like Opal would compile this to >>>> >>>> super initialize. >>>> super setListProperties. >>>> >>>> Intended ? Do we want to keep it? >>>> >>>> NBNativeCodeGen >>>> parseOptions: optionsArray >>>> uses association symbol -> block instead of block -> block >>>> for caseOf arguments. >>>> The old parser does not accept this. >>>> >>>> >>>> >>> >>> >>> -- >>> _,,,^..^,,,_ >>> best, Eliot >>> >> >> > > > -- > _,,,^..^,,,_ > best, Eliot >

Feb. 23, 2016

nautilus does not refresh method changed

by stepharo

Hi may be this is already fixed but in Latest update: #50596 I found myself forced to reopen a class to see its correct method. Stef

Feb. 23, 2016

Re: [Pharo-dev] fully self-contained Linux VM

by Damien Cassou

On February 23, 2016 1:35:48 PM GMT+01:00, "Peter UhnÃ¡k" <i.uhnak(a)gmail.com> wrote: >Hi, > >is it possible to have fully self-contained Linux VM? > >Right now if you want to use Pharo on Linux you have to install some >libraries directly in the system, which isn't particularly >user-friendly. On Linux, do it the Linux way and use a package manager. There are native packages for several distributions and if yours is not covered, you can still use Nix (which I really recommend in any cases). -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Feb. 23, 2016

Re: [Pharo-dev] fully self-contained Linux VM

by Esteban Lorenzano

> On 23 Feb 2016, at 19:05, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Tue, Feb 23, 2016 at 4:42 AM, Nicolai Hess <nicolaihess(a)gmail.com <mailto:nicolaihess@gmail.com>> wrote: > > > 2016-02-23 13:35 GMT+01:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>>: > Hi, > > is it possible to have fully self-contained Linux VM? > > Right now if you want to use Pharo on Linux you have to install some libraries directly in the system, which isn't particularly user-friendly. > > I know that for example libcairo (needed by Roassal) has hard-coded library paths, but maybe this can be changed so the library can be in the zip. > > Could something like that be done also for the remaining lib32 libraries required to run the VM? > > Even if it had to be a special bundle for each linux distribution. > > If you have a 64Bit linux, you may to have include *a lot* of extra libraries. > libcairo (for 32Bit) alone is not enough. You need all the other 32Bit libraries, cairo depends on. > > Not with the 64-bit VM ;-) ans as far as I can foresee, 64bits vms/images will be ready in a couple of monthsâ¦ so do not despair :) Esteban > > > > > Thanks, > Peter > > > > > -- > _,,,^..^,,,_ > best, Eliot

Feb. 23, 2016

Re: [Pharo-dev] fully self-contained Linux VM

by Eliot Miranda

On Tue, Feb 23, 2016 at 4:42 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > 2016-02-23 13:35 GMT+01:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > >> Hi, >> >> is it possible to have fully self-contained Linux VM? >> >> Right now if you want to use Pharo on Linux you have to install some >> libraries directly in the system, which isn't particularly user-friendly. >> >> I know that for example libcairo (needed by Roassal) has hard-coded >> library paths, but maybe this can be changed so the library can be in the >> zip. >> >> Could something like that be done also for the remaining lib32 libraries >> required to run the VM? >> >> Even if it had to be a special bundle for each linux distribution. >> > > If you have a 64Bit linux, you may to have include *a lot* of extra > libraries. > libcairo (for 32Bit) alone is not enough. You need all the other 32Bit > libraries, cairo depends on. > Not with the 64-bit VM ;-) > > > >> >> Thanks, >> Peter >> > > -- _,,,^..^,,,_ best, Eliot

Feb. 23, 2016