February 2016 - Pharo-users

Re: [Pharo-users] Library for shell interfacing on Mac

by Alexandre Bergel

Thanks John. Peter, can you updating the GraphViz layout with OSProcess? That would be really helpful Cheers, Alexandre > On Feb 29, 2016, at 10:54 AM, john pfersich <jpfersich(a)gmail.com> wrote: > > I use OSProcess and CommandShell in Pharo 4.0. Works well. Load them by > > Gofer new > squeaksource: 'OSProcess'; > package: 'OSProcess'; > load. > > Gofer new > squeaksource: 'CommandShell'; > package: 'CommandShell-Piping'; > load. > > and then do something like > > PipeableOSProcess command: 'netstat -a | grep LISTEN | grep 27017' > > On Mon, Feb 29, 2016 at 1:07 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Hi, > > what is the recommended way to execute shell commands on Mac from Pharo? > > Apparently NBMacShell is not supported anymore. > > Thanks, > Peter > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 29, 2016

Re: [Pharo-users] CrashDetector made for sprint

by Thibault Raffaillac

Hi Vincent, I cannot manage to reproduce your bug (on Mac). Can you post the last entry in your .changes file? Cheers, Thibault > Nice! > > I am eager to see it with a better change set manager, i.e. Epicea ;) > > Your tool works nicely when you save and close the image properly. > However, when you close directly the program by clicking on the cross (which > is easier than going into the world menu after a CTRL+SHIFT+S), the image > doesn't crashes, but you get a message to retrieve your changes. > I think that managing this case is harder because you have to interact with > the vm, haven't you? > > Cheers, > Vincent

Feb. 29, 2016

Re: [Pharo-users] Library for shell interfacing on Mac

by john pfersich

Forgot add that this info is from http://pharo.gemtalksystems.com/book/PharoTools/OSProcess/ On Monday, February 29, 2016, john pfersich <jpfersich(a)gmail.com> wrote: > I use OSProcess and CommandShell in Pharo 4.0. Works well. Load them by > > Gofer new > squeaksource: 'OSProcess'; > package: 'OSProcess'; > load. > Gofer new > squeaksource: 'CommandShell'; > package: 'CommandShell-Piping'; > load. > and then do something like > > PipeableOSProcess command: 'netstat -a | grep LISTEN | grep 27017' > > On Mon, Feb 29, 2016 at 1:07 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com > <javascript:_e(%7B%7D,'cvml','i.uhnak(a)gmail.com');>> wrote: > >> Hi, >> >> what is the recommended way to execute shell commands on Mac from Pharo? >> >> Apparently NBMacShell is not supported anymore. >> >> Thanks, >> Peter >> > >

Feb. 29, 2016

Re: [Pharo-users] CrashDetector made for sprint

by Guille Polito

And there it is! http://catalog.pharo.org/catalog/project/CrashDetector?_k=QEAEbx_HCNViU7Bb This is a cool add-on for newbies or image crashers (FFI users for example). On 02/26/2016 05:59 PM, Blondeau Vincent wrote: > Nice! > > I am eager to see it with a better change set manager, i.e. Epicea ;) > > Your tool works nicely when you save and close the image properly. > However, when you close directly the program by clicking on the cross (which is easier than going into the world menu after a CTRL+SHIFT+S), the image doesn't crashes, but you get a message to retrieve your changes. > I think that managing this case is harder because you have to interact with the vm, haven't you? > > Cheers, > Vincent > >> -----Message d'origine----- >> De : Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] De la part de >> Thibault Raffaillac >> EnvoyÃ© : vendredi 26 fÃ©vrier 2016 17:40 >> Ã : pharo-users(a)lists.pharo.org >> Objet : [Pharo-users] CrashDetector made for sprint >> >> Dear Pharo users, >> >> We made a short script with Guille during the Pharo sprint to detect at >> startup when image crashed, and propose to open changes browser to >> recover lost changes. It should be useful for beginners who do not know of >> the Changes Browser. >> >> It should be available tomorrow on Catalog browser, otherwise run: >> Gofer it >> smalltalkhubUser: 'ThibaultRaffaillac' project: 'CrashDetector'; >> configurationOf: 'CrashDetector'; >> loadStable >> >> Patches and comments welcome :) >> Thibault > > !!!************************************************************************************* > "Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un virus transmis. > > This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!" >

Feb. 29, 2016

Re: [Pharo-users] Library for shell interfacing on Mac

by john pfersich

I use OSProcess and CommandShell in Pharo 4.0. Works well. Load them by Gofer new squeaksource: 'OSProcess'; package: 'OSProcess'; load. Gofer new squeaksource: 'CommandShell'; package: 'CommandShell-Piping'; load. and then do something like PipeableOSProcess command: 'netstat -a | grep LISTEN | grep 27017' On Mon, Feb 29, 2016 at 1:07 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > Hi, > > what is the recommended way to execute shell commands on Mac from Pharo? > > Apparently NBMacShell is not supported anymore. > > Thanks, > Peter >

Feb. 29, 2016

Library for shell interfacing on Mac

by Peter UhnÃ¡k

Hi, what is the recommended way to execute shell commands on Mac from Pharo? Apparently NBMacShell is not supported anymore. Thanks, Peter

Feb. 29, 2016

Re: [Pharo-users] A new idea for a project: WarpSpeed (a C inliner)

by Thierry Goubier

Le 29/02/2016 00:32, Ben Coman a Ã©crit : > On Sat, Feb 27, 2016 at 3:30 AM, Dimitris Chloupis > <kilon.alios(a)gmail.com> wrote: >> So now that AsmJit is gone , I had a new idea for a project and I wanted >> your opinion on this if you think it will be useful for the community, I >> call it WarpSpeed. >> >> I was thinking it would still be cool to have some kind of library that will >> help us boost the speed of pharo . So I was thinking about a C inliner >> which is far easier than an Assembly inliner (see AsmJIT) I also found >> TinyC >> >> http://bellard.org/tcc/ >> >> which is as you guessed a tiny c compiler 100kbs in size which i can >> include with a pharo image to allow me to dynamically compile inlined C code >> inside the pharo image so even pharo users without a C compiler installed >> can benefit from it . >> >> That means that if something does not perform as fast as you want you could >> mix C code with pharo code , I am thinking passing the C source code as a >> string or even having the C code in a separate file, and then dynamically >> call the TinyC compiler, compile it to shared library and load if via UFFI >> back to pharo. TinyC is very fast so compilation of the code should be as >> fast if not faster than compiling pharo code. >> >> Looks easy enough to do for a small project by me with the condition there >> are people really interested into something like this. TinyC is licensed as >> LGPL but I can make it fall back to other compilers as well if ones want to >> close the source. >> >> How it sounds as an idea ? > > I've thought about something similar myself, and also looked at tcc. > I think its a really interesting idea, but you need to treat it as an > *experiment* for learning. Whether its ultimately useful to the > community will depend on a lot of things in implementation (I see > Clement indicates some difficulties). > > But maybe tcc is not the right backend. [1] says "Note: I am no longer > working on TCC", the last release dates wehre 2009 & 2013, and [2] > indicates it tcc may be a dead end. > > What would be *really* interesting is, given we have a good > infrastructure to compile Smalltalk to bytecode, investigate some new > constructs to compile to SPIR-V [3]. The specification [4] and > execution/memory model [5] have recently been released. It would be > nice if someone more competent than myself could skim and advise on > the feasibility of such an idea. SPIR-V format is similar to the LLVM-IR and it is quite hard to generate for a language like Smalltalk. Typed operations, SSA, Phi nodes, etc... You get extremely high performance this way, but it is a lot of work. > This presentation [6] starting p38 says SPIRV presents an "opportunity > to unleash innovation: Domain Specific Languages..." which is > typically considered a strength of Smalltalk. p40 says "Compiler split > in two, Front end compiler emits SPIR-V portable binary offline (that > would be us), then SPIR-V is compiled to machine-specific binary by > driver online (that would be just passing the SPIR-V to the GPU > driver). [7] Yes, this is certainly where SPIR-V is interesting: all OpenCL devices would carry a SPIR-V back-end compiler. > Perhaps interesting to see what people are trying in some other languages... > * A bytecode translator like is being tried for Python [A], since SPIR-V is > * End-user tools for working with SPIR-V, disassembling, analysing, > debugging, optimising it, for Go[B] and Python[C]. > > The opportunity in producing tools for working with SPIR-V is you draw > people in for the tool, and they get a side-exposure to our > environment, (which of course they then fall in love with.) The opportunity is more like a compiler infrastructure you'll be writing. If well written, yes, it could be an interesting artefact (training, teaching compilation). Thierry > > [1] http://bellard.org/tcc/ > [2] http://www.landley.net/code/tinycc/ > [3] https://en.wikipedia.org/wiki/Standard_Portable_Intermediate_Representation > [4] https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf > [5] https://www.khronos.org/registry/spir-v/specs/1.0/SPIR-V-execution-and-memo… > [6] > http://vulkan-tutorial.com/assets/Khronos-Vulkan-GDC-Mar15.pdf > [7] http://benedictgaster.org/wp-content/uploads/2012/08/building_700_languages… > > > [A] https://github.com/cheery/spirthon/blob/master/DEV.md > [B] https://github.com/andreas-jonsson/spirv > [C] https://github.com/kristerw/spirv-tools > >

Feb. 28, 2016

Re: [Pharo-users] A new idea for a project: WarpSpeed (a C inliner)

by kilon.alios

TinyC has not similar perfomance to gcc and clang, its actually slower as Stephan already mentioned. Thats the price one has to pay for the much smaller compiler, it loses a lot of optimisations. Clement from what you saying its clear my idea would not work at all, the advantage of tinyC is that is 10 times faster than gcc and clang for compilation but the FFI overheads would kill performance indeed. And if the code becomes much larger it does not make sense to use a C inliner as it would be cleaner and easier to just keep the C code separate. Ben TinyC has been abandoned by the original author but it is now even more actively developed because several people have stepped in his place , its git repo can be found here http://repo.or.cz/w/tinycc.git its not near as actively developed as gcc or clang of course but its not inactive either. Anyway this is obviously a ton more work than I am willing to invest and with no real benefit, so thanks for opening my eyes. Back to something far more simple. -- View this message in context: http://forum.world.st/A-new-idea-for-a-project-WarpSpeed-a-C-inliner-tp4881… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Feb. 28, 2016

SortFunctions

by stepharo

I enjoyed reading this. I do not know if we have this simple but cool lib for Pharo but we should. Stef Objology: TAG-SortFunctions Objology: TAG-SortFunctions Objology: TAG-SortFunctions

Feb. 28, 2016

Re: [Pharo-users] A new idea for a project: WarpSpeed (a C inliner)

by Ben Coman

On Sat, Feb 27, 2016 at 3:30 AM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > So now that AsmJit is gone , I had a new idea for a project and I wanted > your opinion on this if you think it will be useful for the community, I > call it WarpSpeed. > > I was thinking it would still be cool to have some kind of library that will > help us boost the speed of pharo . So I was thinking about a C inliner > which is far easier than an Assembly inliner (see AsmJIT) I also found > TinyC > > http://bellard.org/tcc/ > > which is as you guessed a tiny c compiler 100kbs in size which i can > include with a pharo image to allow me to dynamically compile inlined C code > inside the pharo image so even pharo users without a C compiler installed > can benefit from it . > > That means that if something does not perform as fast as you want you could > mix C code with pharo code , I am thinking passing the C source code as a > string or even having the C code in a separate file, and then dynamically > call the TinyC compiler, compile it to shared library and load if via UFFI > back to pharo. TinyC is very fast so compilation of the code should be as > fast if not faster than compiling pharo code. > > Looks easy enough to do for a small project by me with the condition there > are people really interested into something like this. TinyC is licensed as > LGPL but I can make it fall back to other compilers as well if ones want to > close the source. > > How it sounds as an idea ? I've thought about something similar myself, and also looked at tcc. I think its a really interesting idea, but you need to treat it as an *experiment* for learning. Whether its ultimately useful to the community will depend on a lot of things in implementation (I see Clement indicates some difficulties). But maybe tcc is not the right backend. [1] says "Note: I am no longer working on TCC", the last release dates wehre 2009 & 2013, and [2] indicates it tcc may be a dead end. What would be *really* interesting is, given we have a good infrastructure to compile Smalltalk to bytecode, investigate some new constructs to compile to SPIR-V [3]. The specification [4] and execution/memory model [5] have recently been released. It would be nice if someone more competent than myself could skim and advise on the feasibility of such an idea. This presentation [6] starting p38 says SPIRV presents an "opportunity to unleash innovation: Domain Specific Languages..." which is typically considered a strength of Smalltalk. p40 says "Compiler split in two, Front end compiler emits SPIR-V portable binary offline (that would be us), then SPIR-V is compiled to machine-specific binary by driver online (that would be just passing the SPIR-V to the GPU driver). [7] Perhaps interesting to see what people are trying in some other languages... * A bytecode translator like is being tried for Python [A], since SPIR-V is * End-user tools for working with SPIR-V, disassembling, analysing, debugging, optimising it, for Go[B] and Python[C]. The opportunity in producing tools for working with SPIR-V is you draw people in for the tool, and they get a side-exposure to our environment, (which of course they then fall in love with.) [1] http://bellard.org/tcc/ [2] http://www.landley.net/code/tinycc/ [3] https://en.wikipedia.org/wiki/Standard_Portable_Intermediate_Representation [4] https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.pdf [5] https://www.khronos.org/registry/spir-v/specs/1.0/SPIR-V-execution-and-memo… [6] http://vulkan-tutorial.com/assets/Khronos-Vulkan-GDC-Mar15.pdf [7] http://benedictgaster.org/wp-content/uploads/2012/08/building_700_languages… [A] https://github.com/cheery/spirthon/blob/master/DEV.md [B] https://github.com/andreas-jonsson/spirv [C] https://github.com/kristerw/spirv-tools

Feb. 28, 2016