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

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

by Ben Coman

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. 23, 2016

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

by Peter UhnÃ¡k

> Because we may have code not present and still want to load the code. I think it's just visual, because it's still referenced as string in the pragma itself. For example Person>>contact <DCType: Contact multiplicity: #(1 '*')> ^ contact ifNil: [ contact := OrderedCollection new ] But, (Person>>#contact) pragmas first arguments first class == ByteSymbol Does it fail to load otherwise? Peter On Tue, Feb 23, 2016 at 10:43 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Just emerging from holidays. Is there an effort to have type annotations? > How these annotations are then used? > > Alexandre > > > > On Feb 23, 2016, at 5: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. > > > > Stef > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Feb. 23, 2016

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

by Alexandre Bergel

Just emerging from holidays. Is there an effort to have type annotations? How these annotations are then used? Alexandre > On Feb 23, 2016, at 5: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. > > Stef > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 23, 2016

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

by Tudor Girba

Hi, At the moment, it is used for documentation purposes in Bloc. It is part of the effort of Alex to document Bloc thoroughly. I think it is an interesting idea, in that we would have a significant case study for that can be used later as optional types information to improve static tool support. And it does not hurt at the moment. What do you think? Cheers, Doru > On Feb 23, 2016, at 10:25 AM, Alain Plantec via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > From: Alain Plantec <alain.plantec(a)yahoo.com> > Subject: Re: [Pharo-dev] [Bloc] Do we want <return: #Point> or <return: Point> > Date: February 23, 2016 at 10:23:33 AM GMT+1 > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > > I donât like it too. > Alain > >> Le 23 fÃ©vr. 2016 Ã 09:50, Nicolai Hess <nicolaihess(a)gmail.com> a Ã©crit : >> >> >> >> 2016-02-23 9:47 GMT+01:00 stepharo <stepharo(a)free.fr>: >> 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. >> >> I would like to know for what this is used. >> I don't like it. >> >> >> Stef >> >> > > > -- www.tudorgirba.com www.feenk.com "We are all great at making mistakes."

Feb. 23, 2016

Re: [Pharo-dev] [Bloc] MDLColor and new gradient

by Denis Kudriashov

Hi 2016-02-23 9:13 GMT+01:00 stepharo <stepharo(a)free.fr>: > May be we should have some Palette > > And we could have (brainstorming) > > (ColorBuilder from: MDLPalette) > -> aColorBuilder > aColorBuilder red > -> .... > What the difference between red colors from different palettes? And why it is not just "MDLPalette red"?

Feb. 23, 2016

Re: [Pharo-dev] Why the GTSpotter help does not explain all the categories

by Tudor Girba

Hi Stef, Yes, the title is what you are searching for :). I keep on trying to explain that, but somehow this does not come through. We changed the rendering of the category label to include # in front to make it more apparent. So, if you have a category named #SomeCategoryTitle, you can search for #somec, and you will reduce the amount of processors that get triggered. It is essentially, what you were asking for: if you only want implementors, then you will only search for implementors if you add #implementors (or #i / #im / #imp / #impl / #imple / #implem â¦ ) to your query. The reason it works only with #i is that there is no other category that starts with #i on the top search. I extended the help in the latest version of GT-Spotter with several examples. I will continue extending today with the technical side of how to extend Spotter. Could you take a look to see if it is more explanatory? https://pharo.fogbugz.com/f/cases/17666/GTSpotter-should-offer-usage-help Cheers, Doru > On Feb 23, 2016, at 8:46 AM, stepharo <stepharo(a)free.fr> wrote: > > Doru > > is it the title: 'References' that is used to represent #references? > I do not get it, I have ot guess. Showing people the implementation does not automatically explain. > > The help is missing some text (no idea if this is correct). > > " > Each Extensions methods (e.g. spotterCompositionFor:) defines the category tags that you > can type in the input field > > Point #traits? > Point #composing traits? > > > For the people loving implementation detail, the title of the listProcessor is used as categories. > " > > > Stef > > Le 22/2/16 10:24, Tudor Girba a Ã©crit : >> Hi, >> >> Indeed, this is a problem: >> https://pharo.fogbugz.com/f/cases/17668/Spotter-should-allow-filtering-cate… >> >> Now, I enhanced the category matching to ignore the whitespace. So, now you can say: >> #Classinstancevariables >> >> Another option would be to change the names of categories to have underscore instead of space. Like this: >> #Class_instance_variables >> >> What do you think? >> >> Cheers, >> Doru >> >> >>> On Feb 21, 2016, at 7:22 PM, stepharo <stepharo(a)free.fr> wrote: >>> >>> Thanks but it does not really help understanding. At least I do not get it at all. >>> >>> I have no idea how from >>> >>> Class instance variables >>> >>> I should type something meaningfull. >>> >>> >>> I could get it for Examples, Implementors, Senders because there is only one word. >>> >>> >>> >>> >>> Le 20/2/16 14:34, Tudor Girba a Ã©crit : >>>> We added the mechanism and created a kind of an API entry for documenting all entries within the image. This was one of your request: to know what are all the different searches possible :). >>>> >>>> Doru >>>> >>>> >>>>> On Feb 20, 2016, at 2:26 PM, stepharo <stepharo(a)free.fr> wrote: >>>>> >>>>> Hi >>>>> >>>>> So I tried again to understand how spotter works and I looked at the help and I could not understand >>>>> how I can find class references. >>>>> >>>>> I saw that but it does not show me how I can use it and I do not really want to understand how this is implemented. >>>>> >>>>> spotterReferenceFor: aStep >>>>> <spotterOrder: 30> >>>>> aStep listProcessor >>>>> title: 'References'; >>>>> allCandidates: [ (SystemNavigation default allReferencesTo: self binding) collect: #compiledMethod ]; >>>>> itemName: [ :method | method gtDisplayString ]; >>>>> filter: GTFilterSubstring >>>>> >>>>> >>>>> >>>>> To me this help is totally obscure. >>>>> >>>>> >>>>> Spotter allows the developer to define custom search processors in different classes. These custom processors take effect when Spotter reaches an instance of the extended class. You can find below the list of extensions from this image. >>>>> >>>>> You can also browse this list by inspecting: >>>>> >>>>> GTSpotter spotterExtendingMethods >>>>> >>>>> Behavior >>>>> - Class instance variables (spotterClassInstanceVariablesFor:) >>>>> - Composing traits (spotterCompositionFor:) >>>>> - Instance variables (spotterInstanceVariablesFor:) >>>>> - QA Critics (spotterQACriticsFor:) >>>>> - All subclasses (spotterSubclassesFor:) >>>>> - All superclasses (spotterSuperclassesFor:) >>>>> - Users (spotterTraitUsersFor:) >>>>> - Special Slots (spotterUsedSlotsFor:) >>>>> - Uses Traits (spotterUsedTraitsFor:) >>>>> >>>>> Class >>>>> - Examples (gtSpotterGTExamplesFor:) >>>>> - Class methods (spotterClassMethodsFor:) >>>>> - Instance methods (spotterMethodsFor:) >>>>> - References (spotterReferenceFor:) >>>>> - Super class methods (spotterSuperClassMethodsFor:) >>>>> - Super instance methods (spotterSuperMethodsFor:) >>>>> >>>>> ClassDescription >>>>> - Package (spotterPackageFor:) >>>>> >>>>> Collection >>>>> - spotterItemsFor: (spotterItemsFor:) >>>>> >>>>> CompiledMethod >>>>> - Bytecode (spotterForBytecodesFor:) >>>>> - Implementors (spotterForImplementorsFor:) >>>>> - Senders (spotterForSendersFor:) >>>>> - Class (spotterMethodClassFor:) >>>>> - QA Critics (spotterQACriticsFor:) >>>>> >>>>> Dictionary >>>>> - Keys (spotterForKeysFor:) >>>>> >>>>> FileReference >>>>> - Directories (spotterForDirectoriesFor:) >>>>> - Files (spotterForFilesFor:) >>>>> - Directories (spotterForZipDirectoriesFor:) >>>>> - Files (spotterForZipFilesFor:) >>>>> >>>>> GTExample >>>>> - Example Dependencies (gtSpotterDependenciesFor:) >>>>> - Example Dependents (gtSpotterDependentsFor:) >>>>> - Example Provider (gtSpotterProviderFor:) >>>>> - Example Source (gtSpotterSourceFor:) >>>>> - Example Subjects (gtSpotterSubjectsFor:) >>>>> >>>>> GTExampleFinder >>>>> - Examples (gtSpotterExamplesFor:) >>>>> >>>>> GTExampleFinder class >>>>> - Examples (gtSpotterExamplesFor:) >>>>> >>>>> GTExampleOrganizer >>>>> - Examples (gtSpotterGTExamplesFor:) >>>>> >>>>> GTExampleProxy >>>>> - Example Dependencies (gtSpotterDependenciesFor:) >>>>> - Example Dependents (gtSpotterDependentsFor:) >>>>> >>>>> GTInspector class >>>>> - Extensions (spotterExtensionsFor:) >>>>> >>>>> GTSelectorImplementors >>>>> - Implementors (spotterImplementorsFor:) >>>>> - Senders (spotterSendersFor:) >>>>> >>>>> GTSpotter >>>>> - Examples (gtSpotterExamplesFor:) >>>>> - Catalog Projects (spotterCatalogProjectsFor:) >>>>> - Clipboard History (spotterClipboardFor:) >>>>> - Methods (spotterConcreteMethodFor:) >>>>> - Dirty Monticello packages (spotterDirtyMonticelloPackagesFor:) >>>>> - Playground cached pages (spotterForCachedPlaygroundPagesFor:) >>>>> - Classes (spotterForClassesFor:) >>>>> - Directories (spotterForDirectoriesFor:) >>>>> - Calculator (spotterForExpressionsFor:) >>>>> - Files (spotterForFilesFor:) >>>>> - Global variables (spotterForGlobalVarsFor:) >>>>> - Help topics (spotterForHelpTopicFor:) >>>>> - Messages (spotterForMessagesFor:) >>>>> - Metacello Configurations (spotterForMetacelloConfigurationsFor:) >>>>> - Packages (spotterForPackagesFor:) >>>>> - Pragmas (spotterForPragmasFor:) >>>>> - References (spotterForReferencesFor:) >>>>> - Monticello Repositories (spotterForRepositoriesFor:) >>>>> - Senders (spotterForSendersFor:) >>>>> - spotterForStashedPlaygroundPagesFor: (spotterForStashedPlaygroundPagesFor:) >>>>> - History (spotterHistoryFor:) >>>>> - Implementors (spotterImplementorsFor:) >>>>> - ws.stfx.eu (spotterStfxFor:) >>>>> - Menu (spotterWorldMenuFor:) >>>>> >>>>> GTSpotter class >>>>> - Extensions (spotterExtensionsFor:) >>>>> >>>>> GTSpotterExceptionMock1 >>>>> - mockProcessorFor: (mockProcessorFor:) >>>>> >>>>> GTSpotterExceptionMock2 >>>>> - mockProcessorFor: (mockProcessorFor:) >>>>> >>>>> GTSpotterExceptionMock3 >>>>> - mockProcessorFor: (mockProcessorFor:) >>>>> >>>>> GTSpotterExceptionMock4 >>>>> - mockProcessorFor: (mockProcessorFor:) >>>>> >>>>> GTSpotterExceptionMock5 >>>>> - mockProcessorFor: (mockProcessorFor:) >>>>> >>>>> GlobalVariable >>>>> - Class (spotterClassFor:) >>>>> - References (spotterForReferencesFor:) >>>>> >>>>> HelpTopic >>>>> - Help contents (spotterForHelpTopicFor:) >>>>> >>>>> KMDispatcher >>>>> - Keys (spotterForKeysFor:) >>>>> >>>>> MCPackage >>>>> - Packages (spotterForPackageFor:) >>>>> - Monticello Working Copy (spotterMonticelloWorkingCopyFor:) >>>>> >>>>> MCVersionInfo >>>>> - Ancestors (spotterAncestorsFor:) >>>>> >>>>> MCWorkingCopy >>>>> - All other repositories (spotterAllRepositoriesFor:) >>>>> - Ancestors (spotterAncestorsFor:) >>>>> - Monticello Package (spotterMonticelloPackageFor:) >>>>> - Packages (spotterPackageFor:) >>>>> - Package repositories (spotterPackageRepositoriesFor:) >>>>> >>>>> MenuItemMorph >>>>> - spotterItemsFor: (spotterItemsFor:) >>>>> >>>>> MenuMorph >>>>> - Items (spotterItemsFor:) >>>>> >>>>> MetacelloAbstractPackageSpec >>>>> - Includes (spotterForIncludesFor:) >>>>> - Requires (spotterForRequiresFor:) >>>>> >>>>> MetacelloProject >>>>> - Versions (spotterForVersionsFor:) >>>>> >>>>> MetacelloVersion >>>>> - Groups (spotterForGroupsFor:) >>>>> - Packages (spotterForPackagesFor:) >>>>> >>>>> Morph >>>>> - spotterForKeysFor: (spotterForKeysFor:) >>>>> - Submorphs (spotterForSubmorphsFor:) >>>>> >>>>> PragmaType >>>>> - Pragmas (spotterPragmasFor:) >>>>> - Senders (spotterSendersFor:) >>>>> >>>>> RPackage >>>>> - Classes (spotterClassesFor:) >>>>> - Extension Methods (spotterExtensionMethodsFor:) >>>>> - Monticello Package (spotterMonticelloPackageFor:) >>>>> - Monticello Working Copy (spotterMonticelloWorkingCopyFor:) >>>>> - Tags (spotterTagsFor:) >>>>> >>>>> RPackageTag >>>>> - Classes (spotterClassesFor:) >>>>> >>>>> SettingNode >>>>> - Children (spotterForSettingsFor:) >>>>> >>>>> SettingTree >>>>> - Settings (spotterForSettingsFor:) >>>>> >>>>> Slot >>>>> - Accesses (spotterAccessesFor:) >>>>> >>>>> Trait >>>>> - Examples (gtSpotterGTExamplesFor:) >>>>> - Class methods (spotterClassMethodsFor:) >>>>> - Instance methods (spotterMethodsFor:) >>>>> - References (spotterReferenceFor:) >>>>> - Super class methods (spotterSuperClassMethodsFor:) >>>>> - Super instance methods (spotterSuperMethodsFor:) >>>>> >>>>> TraitBehavior >>>>> - Class instance variables (spotterClassInstanceVariablesFor:) >>>>> - Composing traits (spotterCompositionFor:) >>>>> - Instance variables (spotterInstanceVariablesFor:) >>>>> - QA Critics (spotterQACriticsFor:) >>>>> - All subclasses (spotterSubclassesFor:) >>>>> - All superclasses (spotterSuperclassesFor:) >>>>> - Users (spotterTraitUsersFor:) >>>>> - Special Slots (spotterUsedSlotsFor:) >>>>> - Uses Traits (spotterUsedTraitsFor:) >>>>> >>>>> TraitDescription >>>>> - Package (spotterPackageFor:) >>>>> >>>>> >>>>> >>>> -- >>>> www.tudorgirba.com >>>> www.feenk.com >>>> >>>> "Reasonable is what we are accustomed with." >>>> >>>> >>>> >>> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Quality cannot be an afterthought." >> >> >> > > -- www.tudorgirba.com www.feenk.com âLive like you mean it."

Feb. 23, 2016

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

by Alain Plantec

I donât like it too. Alain > Le 23 fÃ©vr. 2016 Ã 09:50, Nicolai Hess <nicolaihess(a)gmail.com> a Ã©crit : > > > > 2016-02-23 9:47 GMT+01:00 stepharo <stepharo(a)free.fr <mailto:stepharo@free.fr>>: > 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. > > I would like to know for what this is used. > I don't like it. > > > Stef > >

Feb. 23, 2016

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

by Nicolai Hess

2016-02-23 9:47 GMT+01:00 stepharo <stepharo(a)free.fr>: > 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. > I would like to know for what this is used. I don't like it. > > Stef > >

Feb. 23, 2016

[Bloc] Do we want <return: #Point> or <return: Point>

by stepharo

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. Stef

Feb. 23, 2016

[Bloc] dispatcher vs shortcutHandler

by stepharo

Hi what is the diff between kmDispatcher and shotcutHandler? Stef

Feb. 23, 2016