- Pharo-dev - lists.pharo.org

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

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

by Eliot Miranda

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? > 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

Re: [Pharo-dev] [Bloc] Do we want <return: #Point> or <return: Point>

by Eliot Miranda

On Tue, Feb 23, 2016 at 12:47 AM, stepharo <stepharo(a)free.fr> wrote: > Hi > > I saw that something <return: #Point> or <return: Point> > I do not know why but I have the impression that <return: #Point> is > better. > Because we may have code not present and still want to load the code. > Given the current semantics of pragmas only <return: #Point> is valid. _,,,^..^,,,_ best, Eliot

Feb. 23, 2016

curiousity, ensure unwind block priority inheritance

by Ben Coman

Just thought I'd share something enlightening I learnt today, a curious surprise... When a process is terminated, the #ensure: unwind block effectively inherits the priority of the terminator process. Thus the following... log := OrderedCollection new. s := Semaphore new. p := [ [ log add: 1. s signal. log add: 4. ] ensure: [log add: 5] ] forkAt: 30. s wait. log add: 2. "p terminate." log add: 3. 100 milliSeconds wait. Transcript crShow: log. ...gives {1 2 3 4 5} as expected. However uncommenting the terminate statement produces {1 2 5 3}. Quite non-intuitive** to have the "5" code inside the priority 30 block execute before the "3" code of the priority 40 of the UI/Playground. **meaning it bit me for a few hours trying to understand some ProcessTests related to Case 17588. cheers -ben

Feb. 23, 2016