May 2017 - Pharo-users - lists.pharo.org

Issue with Pillar

by Alexandre Bergel

Hi! I am trying to get Pillar working on OS X. I followed the instruction given on https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessf… I did: curl https://raw.githubusercontent.com/pillar-markup/pillar/master/download.sh | bash ./pillar archetype welcome make book-result/welcome.html The two first instruction do not seem to cause any trouble. Work as expected. The make instruction produces: -=-=-=-= /tmp/pillar> make book-result/welcome.html mkdir -p ./book-result find . -type d -path ./book-result -prune -o -wholename "*/figures" -exec cp {} --parents -r ./book-result \; cp -r support/ ./book-result ./pillar export --to=html --outputDirectory=./book-result --outputFile=welcome.pillar welcome.pillar MessageNotUnderstood: FileReference>>jsonWriteOn: FileReference(Object)>>doesNotUnderstand: #jsonWriteOn: [ :assoc | needComma ifTrue: [ aStream nextPut: $, ] ifFalse: [ needComma := true ]. assoc key jsonWriteOn: aStream. aStream nextPut: $:. assoc value jsonWriteOn: aStream ] in Dictionary>>jsonWriteOn: in Block: [ :assoc | ... [ :each | each ifNotNil: [ aBlock value: each ] ] in Dictionary>>associationsDo: in Block: [ :each | each ifNotNil: [ aBlock value: each ] ] Array(SequenceableCollection)>>do: Dictionary>>associationsDo: Dictionary>>jsonWriteOn: PRExportPhase>>asJson:withConfiguration: [ :outStream | self writeOutput: (self asJson: output withConfiguration: cocoonConfiguration) toStream: outStream ] in PRExportPhase>>write:using: in Block: [ :outStream | ... [ aBlock value: stream ] in FileReference(AbstractFileReference)>>writeStreamDo: in Block: [ aBlock value: stream ] BlockClosure>>ensure: FileReference(AbstractFileReference)>>writeStreamDo: FileReference(AbstractFileReference)>>pillarWriteDuring: PRExportPhase>>outputStreamDuring: PRExportPhase>>write:using: PRExportPhase>>actionOn: PRExportPhase class(PRPhase class)>>executeOn: [ :input | self executeOn: input ] in PRExportPhase class(PRPhase class)>>buildPipe: in Block: [ :input | self executeOn: input ] LPPhase>>executeOn: [ :subResult :next | next executeOn: subResult ] in LPPipeline>>executeOn: in Block: [ :subResult :next | next executeOn: subResult ] [ :each | nextValue := binaryBlock value: nextValue value: each ] in OrderedCollection(Collection)>>inject:into: in Block: [ :each | nextValue := binaryBlock value: nextValu...etc... OrderedCollection>>do: OrderedCollection(Collection)>>inject:into: LPPipeline>>executeOn: PRPillarConfiguration>>export [ :exporter | (configuration getConfigurationNamed: exporter) export ] in [ configuration defaultExporters do: [ :exporter | (configuration getConfigurationNamed: exporter) export ] ] in PRExportCommandLineHandler>>export in Block: [ :exporter | (configuration getConfigurationNamed...etc... Array(SequenceableCollection)>>do: [ configuration defaultExporters do: [ :exporter | (configuration getConfigurationNamed: exporter) export ] ] in PRExportCommandLineHandler>>export in Block: [ configuration defaultExporters... BlockClosure>>on:do: PRExportCommandLineHandler>>export PRExportCommandLineHandler>>activate make: *** [book-result/welcome.html.json] Error 1 rm book-result/welcome.html.json -=-=-=-= Any idea whatâs wrong? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 10, 2017

Petri nets and workflow patterns

by Norbert Hartl

Are there any resources regarding petri nets or control flowâ¦/workflow patterns in pharo or smalltalk? thanks, Norbert

May 10, 2017

Re: [Pharo-users] Working with remote debugger: how to debug something happening in the remote image ?

by Steven Costiou

It works :) Thanks :) Le 2017-05-10 14:22, Denis Kudriashov a Ã©crit : > 2017-05-10 13:49 GMT+02:00 Steven Costiou <steven.costiou(a)kloum.io>: > >> Then i do openPlayground and TestClass new inspect -> i got an inspector on the proxy object. If i do "self test inspect" inside it, i got the same debugger opening, telling me the error but with the "proxy stack" and not the test method where the problem is. Basically it seems that everything i try to remotely execute from the local image falls into this case. I did not try to start a process when starting the remote image so maybe this works. My question is, is there a way to remotely execute (user) code that will open the debugger on the "right" stack ? (or did i do something wrong ?) > > Currently to get real debugger from playground script you need evaluate fork over expression. For example following code in remote playground: > >> [1/0] fork > > it will open debugger on remote process. But if you just execute "1/0" then you will got local debugger with "RemoteException~" title without remote stack. > > It works like that because remote request itself handles failures and transfers them as result back to local image. It is suitable strategy for many cases and it is most simple and safe to implement. But now there is no way how to setup another strategy to open remote debugger. > So to escape internal communication handler you need fork evaluated expression. When remote image produces unhandled error it will spawn debugger which will be connected remote debugger in our case. That's why #fork is needed: to ensure unhandled failures. > > I not hide this specifics inside remote playground because during debugging of all this remote tools it is suitable to just see communication failure instead of remote debugger. When remote debugger is opening it also communicates with remote side and if communication logic is broken it leads to infinite recursion and frozen image. > In future I will make this behaviour natural (like in local playground) but right now my scenario is: > - evaluate desired code in playground. > - if It fails ( RemoteException with description of actual failure) then wrap it with fork and got remote debugger.

May 10, 2017

Re: [Pharo-users] Working with remote debugger: how to debug something happening in the remote image ?

by Denis Kudriashov

2017-05-10 13:49 GMT+02:00 Steven Costiou <steven.costiou(a)kloum.io>: > Then i do openPlayground and TestClass new inspect â> i got an inspector > on the proxy object. If i do "self test inspect" inside it, i got the same > debugger opening, telling me the error but with the "proxy stack" and not > the test method where the problem is. Basically it seems that everything i > try to remotely execute from the local image falls into this case. I did > not try to start a process when starting the remote image so maybe this > works. My question is, is there a way to remotely execute (user) code that > will open the debugger on the "right" stack ? (or did i do something wrong > ?) Currently to get real debugger from playground script you need evaluate fork over expression. For example following code in remote playground: [1/0] fork it will open debugger on remote process. But if you just execute "1/0" then you will got local debugger with "RemoteException~" title without remote stack. It works like that because remote request itself handles failures and transfers them as result back to local image. It is suitable strategy for many cases and it is most simple and safe to implement. But now there is no way how to setup another strategy to open remote debugger. So to escape internal communication handler you need fork evaluated expression. When remote image produces unhandled error it will spawn debugger which will be connected remote debugger in our case. That's why #fork is needed: to ensure unhandled failures. I not hide this specifics inside remote playground because during debugging of all this remote tools it is suitable to just see communication failure instead of remote debugger. When remote debugger is opening it also communicates with remote side and if communication logic is broken it leads to infinite recursion and frozen image. In future I will make this behaviour natural (like in local playground) but right now my scenario is: - evaluate desired code in playground. - if It fails ( RemoteException with description of actual failure) then wrap it with fork and got remote debugger.

May 10, 2017

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

by nacho

Kilion, In Haskell (a language that I love, just as Smalltalk) you have the REPL. The workflow is, while you are working on the project, you periodically load that file into the REPL and check. After that you compile. Haskell works with a strong type inference feature, however most Haskellers will say that the best practice is to annotate all functions. Also if you are on macOS you have: http://haskellformac.com/ which is awesome, really a great piece of software. There was even a project called Kronos that was essentially the same as IPython but with a Haskell kernel I don't know the status of that project as of today, I really never used it. just my 2c best Nacho ----- Nacho Smalltalker apprentice. Buenos Aires, Argentina. -- View this message in context: http://forum.world.st/Smalltalkers-will-eventually-win-So-says-this-old-C-p… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 10, 2017

Re: [Pharo-users] Working with remote debugger: how to debug something happening in the remote image ?

by Steven Costiou

> If you want to fight with it then my first idea would be to find how method AST is built in sugs menu. Then try to look at senders of #astForStylingInCalypso which was implemented to support styling of remote methods. Try to use it somehow for sugs menu too. > Maybe it will fix everything Yes, i will have a look - i need the right click menu to properly work so i need that to be fixed. The workaround i used was to just disable suggestions by returning empty suggs collections, but i will see if i can do something better. Thanks Denis.

May 10, 2017

Re: [Pharo-users] Working with remote debugger: how to debug something happening in the remote image ?

by Steven Costiou

Ok, so there is this problem. I just wanted to try the debugger on it. But i have the same problem with my own user code. For example i did open a remote browser, create a test package with a class TestClass and a method test>>^'1', 0. Then i do openPlayground and TestClass new inspect -> i got an inspector on the proxy object. If i do "self test inspect" inside it, i got the same debugger opening, telling me the error but with the "proxy stack" and not the test method where the problem is. Basically it seems that everything i try to remotely execute from the local image falls into this case. I did not try to start a process when starting the remote image so maybe this works. My question is, is there a way to remotely execute (user) code that will open the debugger on the "right" stack ? (or did i do something wrong ?) Le 2017-05-10 13:21, Denis Kudriashov a Ã©crit : > Problem that right now many thinks in browser are not supported in remote scenario: most of refactorings are not work and as you see suggestion menu not works too. > > It is local tools problem, the way how local tools communicate with remote environment to perform particular operations. When you try debug such operations local debugger stops at the place of remote request. Distributed debugger (which shows multiple process stacks) is not done. But it will not help here. > > Generally there are many cases when transparent remoting is not working. And to fix concrete scenario proper model is needed which is taken into account that it can be distributed across network borders. > In this case suggestion menu operates with local AST-nodes of remote method which is required non trivial logic to be handled properly. > > Anyway these features will be supported in future.. > > 2017-05-10 11:28 GMT+02:00 Steven Costiou <steven.costiou(a)kloum.io>: > >> While configuring my local and remote images to work with the remote debugger, there was a bug with the menu in the remote browser. So i wanted to try the debugger and figure out what was the problem using it, but i do not understand how to proceed. When the debugger opens, all i see is the fact that there was a remote problem, and that the proxy was unable to return a proper value. >> >> I used a local image connected with a headless remote image. To reproduce the bug, go for example in ByteString >> at:put:, right click after the first dot and click "debug". See suggs-menu-bug.png. >> >> When doing that i get debug-win.png and suggs-debug.png and as you can see i just know there was an error and what it was but i don't have an open debugger as i would normally expect in Pharo. How can i see the real problem occuring in the remote image ? How can i remotely fix this considering that my remote image is headless and it seems to be a problem tied to the remote thing, because locally it doesn't happen ? (or maybe it is a Calypso problem but anyway i cannot debug it...) >> >> Steven.

May 10, 2017

Re: [Pharo-users] Smalltalkers will, eventually, win. So says this old C++ programmer.

by askoh

Kilon: This is revelation to me. I am enduring 10 minute turnaround for every edit I make in *.java, xml, jsp, js files. 4 minute compile and 6 minute web server update. How can I get that shortened to 10 seconds say? What links can help? What search terms to google? Thanks, Aik-Siong Koh > On May 10, 2017, at 3:20 AM, kilon.alios [via Smalltalk] <ml+s1294792n4946404h48(a)n4.nabble.com> wrote: > > Just to remind people here that all languages with long compile times can be avoided live coding style through the use of dynamically linked libraries known as DLLs on windows, shared libraries on linux (*.so) and macos (*.dylib) . Also Swift in particular comes with a live coding environment called "Playgrounds" which is also very flexible. > > Haskell do not know if they have something similar to Playgrounds but I will be surprise if they do not have something at least inferior. All languages support DLLs including ours. > > Live coding is actually super easy to implement and believe me I was sceptical about it at first and if I had read this post I am making now I would call me crazy. But after implementing live coding in python, C and C++ , now I am a believer. Of course the real question here is if its that easy why people do not use it . From what I have found out, it has not occurred to them as it did not occur to me. > > Why C++ coders still endure long compile times when they could test code in an instant through live coding ? Well in games C++ live coding is actually very popular, so some are already aware of the huge advantages of live coding. > > I think this is an advantage of Pharo , that introduces to live coding, a so simple idea yet so essential without you having to think about it yourself or be already aware of it. > > With other language you will have to find a tutorial or article that mentions this ability. > > Another shock for me is how simple it is to implement an image file format for other languages. The shock was that the OS already uses image files like pharo image that calls them "memory mapped files" they are used for sharing memory which in turn is what is used for DLLs. The advantage over the pharo image is that it crash prone, because it is handled by the OS and not the language or the VM. Which means that even if your app crashes the image is still saved and you lose no live data which is not the case with pharo image. The disadvantage is that of course they are not OOP friendly as the pharo image is and they are not language specific as pharo image is. > > Again I would not have known any of this if I had not been playing with shared memory as an IPC and I also see coders rarely if ever mentioning them. > > > >> On Wed, May 10, 2017 at 4:09 AM Pierce Ng <[hidden email]> wrote: >> On Tue, May 09, 2017 at 06:59:08PM +0200, Stephan Eggermont wrote: >> > I don't know. I do know that I can't use something with the >> > ridiculous compile times of Haskell or Swift. That just kills flow >> > and productivity. >> >> You could hop onto an office chair and engage your colleague in sword fighting. >> That's a plus! :-) >> >> Pierce >> > > > If you reply to this email, your message will be added to the discussion below: > http://forum.world.st/Smalltalkers-will-eventually-win-So-says-this-old-C-p… > To unsubscribe from Smalltalkers will, eventually, win. So says this old C++ programmer., click here. > NAML -- View this message in context: http://forum.world.st/Smalltalkers-will-eventually-win-So-says-this-old-C-p… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

May 10, 2017

Re: [Pharo-users] Working with remote debugger: how to debug something happening in the remote image ?

by Denis Kudriashov

2017-05-10 11:28 GMT+02:00 Steven Costiou <steven.costiou(a)kloum.io>: > How can i remotely fix this considering that my remote image is headless > and it seems to be a problem tied to the remote thing, because locally it > doesn't happen ? (or maybe it is a Calypso problem but anyway i cannot > debug it...) If you want to fight with it then my first idea would be to find how method AST is built in sugs menu. Then try to look at senders of #astForStylingInCalypso which was implemented to support styling of remote methods. Try to use it somehow for sugs menu too. Maybe it will fix everything

May 10, 2017

Re: [Pharo-users] Working with remote debugger: how to debug something happening in the remote image ?

by Denis Kudriashov

Problem that right now many thinks in browser are not supported in remote scenario: most of refactorings are not work and as you see suggestion menu not works too. It is local tools problem, the way how local tools communicate with remote environment to perform particular operations. When you try debug such operations local debugger stops at the place of remote request. Distributed debugger (which shows multiple process stacks) is not done. But it will not help here. Generally there are many cases when transparent remoting is not working. And to fix concrete scenario proper model is needed which is taken into account that it can be distributed across network borders. In this case suggestion menu operates with local AST-nodes of remote method which is required non trivial logic to be handled properly. Anyway these features will be supported in future.. 2017-05-10 11:28 GMT+02:00 Steven Costiou <steven.costiou(a)kloum.io>: > While configuring my local and remote images to work with the remote > debugger, there was a bug with the menu in the remote browser. So i wanted > to try the debugger and figure out what was the problem using it, but i do > not understand how to proceed. When the debugger opens, all i see is the > fact that there was a remote problem, and that the proxy was unable to > return a proper value. > > I used a local image connected with a headless remote image. To reproduce > the bug, go for example in ByteString >> at:put:, right click after the > first dot and click "debug". See suggs-menu-bug.png. > > When doing that i get debug-win.png and suggs-debug.png and as you can see > i just know there was an error and what it was but i don't have an open > debugger as i would normally expect in Pharo. How can i see the real > problem occuring in the remote image ? How can i remotely fix this > considering that my remote image is headless and it seems to be a problem > tied to the remote thing, because locally it doesn't happen ? (or maybe it > is a Calypso problem but anyway i cannot debug it...) > > > > Steven. >

May 10, 2017