- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] GToolkit

by Esteban A. Maringolo

2014-09-15 14:50 GMT-03:00 Tudor Girba <tudor(a)tudorgirba.com>: > Hi Estaban, > > On Mon, Sep 15, 2014 at 3:30 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: >> >> 2014-09-14 15:53 GMT-03:00 Tudor Girba <tudor(a)tudorgirba.com>: >> > Hi Phil, >> >> > It would be cool to know the reasons why people have to use other tools. >> > Perhaps we can do something about it. >> >> If it involves text edition or manipulation, I use external tools >> because of the lack of certain features in Pharo workspaces (or even >> syntax highlighting limits) or due to the comfort I find in using the >> same key bindings/shortcuts I use everywhere to edit a csv file, SQL >> script, chunk or whatever. That's one of the reasons. :) > Could we go into details here? I am genuinely interested in collected these > use cases. Sure. > As noted before, syntax highlighting is now supported in GToolkit via > Rubric. I haven't used Rubric. So I can't really talk about it. But text editing speed in Pharo is perceivable slower than, ej, Notepad++ or gVim. It won't affect the normal use, because most methods are small, but as the code gets larger it slows down (exponentially?). > What kind of keybindings are we talking about? I'm referring to common Windows keybindings: Ctrl+arrow, Ctrl+Home, Ctrl+Shift+End, Ctrl+F, Ctrl+H, Ctrl+A, etc. Some are supported by Pharo, others don't. Regards! Esteban A. Maringolo

Sept. 15, 2014

Re: [Pharo-dev] TestCoverage magic?

by Yuriy Tymchuk

Thanks, because I started to think that this are things beyond my OO knowledge :) Uko > On 15 Sep 2014, at 18:42, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > It might be that it just does not work right now... > > On Mon, Sep 15, 2014 at 5:53 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com <mailto:yuriy.tymchuk@me.com>> wrote: > Hi everyone, > > Iâm trying to understand how current coverage works and executing "TestCoverage new" returns nilâ¦ and "TestCoverage class>>#on:â sends #initializeOn: to that nil. > > Iâll be very thankful for explanation. > Uko > > > > -- > -- > Marcus Denker -- denker(a)acm.org <mailto:denker@acm.org> > http://www.marcusdenker.de <http://www.marcusdenker.de/>

Sept. 15, 2014

#doSemanticAnalysisIn: error

by Esteban A. Maringolo

>From time to time when I halt the execution (or try to halt it) I get walkbacks reporting a MNU in nil #doSemanticAnalaysisIn: nil Now after hiting Alt+. for a while I was able to recover the control of the image, but when selecting the "Morphic UI process" in the process explorer I get a similar walkback (see screenshot). Why is this? Is it a know bug? Esteban A. Maringolo

Sept. 15, 2014

Re: [Pharo-dev] GToolkit

by Tudor Girba

Hi Estaban, On Mon, Sep 15, 2014 at 3:30 AM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2014-09-14 15:53 GMT-03:00 Tudor Girba <tudor(a)tudorgirba.com>: > > Hi Phil, > > > It would be cool to know the reasons why people have to use other tools. > > Perhaps we can do something about it. > > If it involves text edition or manipulation, I use external tools > because of the lack of certain features in Pharo workspaces (or even > syntax highlighting limits) or due to the comfort I find in using the > same key bindings/shortcuts I use everywhere to edit a csv file, SQL > script, chunk or whatever. That's one of the reasons. :) > Could we go into details here? I am genuinely interested in collected these use cases. As noted before, syntax highlighting is now supported in GToolkit via Rubric. What kind of keybindings are we talking about? Another one is that I found the option to do things externally to be > "safer" than relying on a unique tool to do all the tasks. > "Rule of Composition" and "Rule of Modularity" according to the Unix > Philosophy. Not to mention the "Rule of Parsimony": Write a big program only when > it is clear by demonstration that nothing else with do. :) > I think we should not mistaken big for powerful and neither should we do it the other way around. If there is anything we show in Pharo is that we can do small and powerful. But, please keep in mind that I am referring to activities that you would like to do without leaving your objects. Cheers, Doru > Regards! > > Esteban A. Maringolo > > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 15, 2014

Re: [Pharo-dev] TestCoverage magic?

by Marcus Denker

Hi, It might be that it just does not work right now... On Mon, Sep 15, 2014 at 5:53 PM, Yuriy Tymchuk <yuriy.tymchuk(a)me.com> wrote: > Hi everyone, > > Iâm trying to understand how current coverage works and executing > "TestCoverage new" returns nilâ¦ and "TestCoverage class>>#on:â sends > #initializeOn: to that nil. > > Iâll be very thankful for explanation. > Uko > -- -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Sept. 15, 2014

Re: [Pharo-dev] Parsing Pharo syntax to C/C++

by phil＠highoctane.be

On Mon, Sep 15, 2014 at 6:23 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi All, > > On Mon, Sep 15, 2014 at 6:01 AM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> >> >> 2014-09-15 14:39 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: >> >>> Hello, >>> >>> Note that slang is a subset of smalltalk. The Slang compiler does not >>> allow to compile smalltalk to C. It allows to compile a smalltalk with >>> restricted message sends and classes to C. >>> >> >> Yes, I am aware of that. I remember that from the very beginnings of >> Squeak. >> >> Wasn't Smalltalk/X the one which had a more complete version of that C >> translation? I did an internship in a French company who had a Smalltalk to >> C translator done for them a long time ago. >> >> >>> >>> 2014-09-15 13:28 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: >>> >>>> Hi Phil, >>>> >>>> thanks for the update on Slang to C. Allways significant to have that. >>>> >>> >>>> Two open questions: >>>> >>>> - would a slang to x86 asm via NativeBoost be doable / a nice target? >>>> >>> >>> Yes it would be interesting. However, by having a Slang to C compiler, >>> we're platform-independent, we can compile the C code to x86, x86_64 and >>> ARM quite easily (some part of the VM are already processor dependent, but >>> not so much). Targeting direct machine code implies evolving the Slang >>> compiler for each new assembly code we support. It sounds like a lot of >>> engineering work compared to our resources and the gain. >>> >> >> It would allow JIT-type compilation experiments than a Slang-to-C chain >> isn't designed for :) With a lot more work doing the various NB ports, of >> course. >> >> >>> >>>> - would targetting LLVM-IR be of interest? >>>> >>>> If you compile the C code with Clang instead of gcc, which starts to be >>> the case because of the lack of support for gcc in the latest Mac OS X, you >>> are already using LLVM IR because Clang uses it. As the VM use the GNU C >>> extensions to improve performance, I do not think that targeting directly >>> the LLVM IR would greatly improve performance. So it sounds like quite some >>> engineering work for no gain. >>> >> >> I would not suggest replacing C by LLVM-IR for VM work, in part because >> LLVM-IR is not what I would call a readable source code format... But I do >> know that even when doing C to C rewritting for embedded compilation, there >> is some low-level code that you can't write in C. >> > > I find this whole discussion depressing. It seems people would rather put > their energy in chasing quick fixes or other technologies instead of > contributing to the work that is being done in the existing VM. > Why so? I am all in for using the VM based technology. Slang is great. Now, we need to interface with the outside world, and then it is C-based at one point. > People discuss using LLVM as if the code generation capabilities inside > Cog were somehow poor or have no chance of competing. Spur is around twice > as fast as the current memory manager, has much better support for the FFI. > ClÃ©ment and I, now with help from Ronie, are making excellent progress > towards an adaptive optimizer/speculative inliner that will give us similar > performance to V8 (the Google JavaScript VM, lead by Lars Bak, who > implemented the HotSpot VM (Smalltalk and Java)) et al. > Super, that's why I bet my company business on Pharo for software development. I trust you guys. > We are trying to get person-power for a high-quality FFI and have a > prototype for a non-blocking VM. When we succeed C won't be any better and > so it won't be an interesting target. One will be able to program entirely > in Smalltalk and get excellent performance. But we need effort. > Collaboration. > Ah, non blocking VM, a super cool thing to have. I am going through hoops at the moment to avoid doing direct SNMP calls to devices from Pharo... > > Personally I feel so discouraged when people talk about using LLVM or > libffi or whatever instead of having the courage and energy to make our > system world-class. I have the confidence in our abilities to compete with > the best and am saddened that people in the community don't value the > technology we already have and can't show faith in our abilities to improve > it further. Show some confidence and express support and above all get > involved. > That's well said. Let's race to the top! > > Collaborators <http://www.mirandabanda.org/cogblog/collaborators/> > Cog Projects <http://www.mirandabanda.org/cogblog/cog-projects/> > Spur 1/3 > <https://www.youtube.com/watch?v=k0nBNS1aHZ4&index=49&list=PLJ5nSnWzQXi_6yyR…> > Spur, a new object representa... > <http://www.slideshare.net/esug/spur-a-new-object-representation-for-cog> > Sista: Improving Cog's JIT performance 1/2 > <https://www.youtube.com/watch?v=X4E_FoLysJg&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Y…> > Sista: Improving Cogâs JIT pe > <http://www.slideshare.net/esug/sista-talkesug2>.. > Lowcode: Redoing NativeBoost ... > <http://www.slideshare.net/esug/03-lowcodeslides> > All very interesting things indeed. Now, doing application level code at the moment, I can't really dig into these. But I can use them and kick ass! > > > However, I think Ronie was interested in doing such work. If he succeeds >>> and reports performance improvement, then we can consider using his >>> compiler to compile the VM. >>> >> >> Keep us posted! >> >> Thierry >> > > -- > in hope, > > Eliot >

Sept. 15, 2014

Re: [Pharo-dev] Parsing Pharo syntax to C/C++

by Eliot Miranda

Hi All, On Mon, Sep 15, 2014 at 6:01 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2014-09-15 14:39 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > >> Hello, >> >> Note that slang is a subset of smalltalk. The Slang compiler does not >> allow to compile smalltalk to C. It allows to compile a smalltalk with >> restricted message sends and classes to C. >> > > Yes, I am aware of that. I remember that from the very beginnings of > Squeak. > > Wasn't Smalltalk/X the one which had a more complete version of that C > translation? I did an internship in a French company who had a Smalltalk to > C translator done for them a long time ago. > > >> >> 2014-09-15 13:28 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: >> >>> Hi Phil, >>> >>> thanks for the update on Slang to C. Allways significant to have that. >>> >> >>> Two open questions: >>> >>> - would a slang to x86 asm via NativeBoost be doable / a nice target? >>> >> >> Yes it would be interesting. However, by having a Slang to C compiler, >> we're platform-independent, we can compile the C code to x86, x86_64 and >> ARM quite easily (some part of the VM are already processor dependent, but >> not so much). Targeting direct machine code implies evolving the Slang >> compiler for each new assembly code we support. It sounds like a lot of >> engineering work compared to our resources and the gain. >> > > It would allow JIT-type compilation experiments than a Slang-to-C chain > isn't designed for :) With a lot more work doing the various NB ports, of > course. > > >> >>> - would targetting LLVM-IR be of interest? >>> >>> If you compile the C code with Clang instead of gcc, which starts to be >> the case because of the lack of support for gcc in the latest Mac OS X, you >> are already using LLVM IR because Clang uses it. As the VM use the GNU C >> extensions to improve performance, I do not think that targeting directly >> the LLVM IR would greatly improve performance. So it sounds like quite some >> engineering work for no gain. >> > > I would not suggest replacing C by LLVM-IR for VM work, in part because > LLVM-IR is not what I would call a readable source code format... But I do > know that even when doing C to C rewritting for embedded compilation, there > is some low-level code that you can't write in C. > I find this whole discussion depressing. It seems people would rather put their energy in chasing quick fixes or other technologies instead of contributing to the work that is being done in the existing VM. People discuss using LLVM as if the code generation capabilities inside Cog were somehow poor or have no chance of competing. Spur is around twice as fast as the current memory manager, has much better support for the FFI. ClÃ©ment and I, now with help from Ronie, are making excellent progress towards an adaptive optimizer/speculative inliner that will give us similar performance to V8 (the Google JavaScript VM, lead by Lars Bak, who implemented the HotSpot VM (Smalltalk and Java)) et al. We are trying to get person-power for a high-quality FFI and have a prototype for a non-blocking VM. When we succeed C won't be any better and so it won't be an interesting target. One will be able to program entirely in Smalltalk and get excellent performance. But we need effort. Collaboration. Personally I feel so discouraged when people talk about using LLVM or libffi or whatever instead of having the courage and energy to make our system world-class. I have the confidence in our abilities to compete with the best and am saddened that people in the community don't value the technology we already have and can't show faith in our abilities to improve it further. Show some confidence and express support and above all get involved. Collaborators <http://www.mirandabanda.org/cogblog/collaborators/> Cog Projects <http://www.mirandabanda.org/cogblog/cog-projects/> Spur 1/3 <https://www.youtube.com/watch?v=k0nBNS1aHZ4&index=49&list=PLJ5nSnWzQXi_6yyR…> Spur, a new object representa... <http://www.slideshare.net/esug/spur-a-new-object-representation-for-cog> Sista: Improving Cog's JIT performance 1/2 <https://www.youtube.com/watch?v=X4E_FoLysJg&list=PLJ5nSnWzQXi_6yyRLsMMBqG8Y…> Sista: Improving Cogâs JIT pe <http://www.slideshare.net/esug/sista-talkesug2>.. Lowcode: Redoing NativeBoost ... <http://www.slideshare.net/esug/03-lowcodeslides> However, I think Ronie was interested in doing such work. If he succeeds >> and reports performance improvement, then we can consider using his >> compiler to compile the VM. >> > > Keep us posted! > > Thierry > -- in hope, Eliot

Sept. 15, 2014

TestCoverage magic?

by Yuriy Tymchuk

Hi everyone, Iâm trying to understand how current coverage works and executing "TestCoverage new" returns nilâ¦ and "TestCoverage class>>#on:â sends #initializeOn: to that nil. Iâll be very thankful for explanation. Uko

Sept. 15, 2014

Re: [Pharo-dev] Tests around Pharo

by Ben Coman

mschepens wrote: > First of all, thank you for your answers, your precious advices and for > having taken time to answer us. > Answers to Ben Coman : > It's our first experience with Pharo, but we'll take more time to learn this > project if it's necessary. > We're a little comfortable with the tool, we already took the time to > discover it, to do the first tutorial which is proposed when pharo is > launched, and to develop first classes and tests for learning about pharo. > We never used the TestRunner previously, we just ran our tests for our > classes yesterday. > We never submitted a code Slice for Intergration before. > > We're still waiting propositions of Test or code to cover, and again thank > you for your attention. > > So there was the "contractTo:" example that I provided. This provides a simple end-to-end practice example for getting "some" code integrated into Pharo. Try that first. Now perhaps no one has a "list" missing tests. Either new tests get written together with new system code, or just when people bump into problems. Open source is about scratching your own itch, and learning how to discover gaps is nearly as important a skill as filling them. Did you try my recipe to find gaps? Report what you found, then it is less of a burden for all to review and advise on those, than for us to do this task for you. Now an alternative recipe to find gaps is in the Browser, scroll down to Collections-** and for various classes look in the "testing" protocol of the third pane, then right-click of various methods and choose "Senders of..." to see if it is sent from a test method. btw, it is just co-incidence the protocol is called "testing". This is the general protocol for method that return a "true or false" result. I'd chose this to start with since it should be simpler to work out what each method does from looking at its Senders, and how to write a test for it, than other infrastructure methods. Now you may find it useful to review.... http://www.catb.org/esr/faqs/smart-questions.html Good luck with it, and I feel free to ask more questions. cheers -ben

Sept. 15, 2014

Re: [Pharo-dev] How often should a uninitializedvariable warning be shown?

by Esteban A. Maringolo

Not strictly related, but I'd love to have notifications about syntax errors without modifying the code. It gets really nasty when there is a missing square bracket or parenthesis. :) Esteban A. Maringolo 2014-09-15 11:47 GMT-03:00 kilon alios <kilon.alios(a)gmail.com>: > maybe pop up a dialog with the choice for the user to suppress any other > warnings of same kind. > > On Mon, Sep 15, 2014 at 4:28 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: >> >> Does it make sense to warn more than once for each variable? >> >> Stephan >> >> distibutionMapOn: a >> a roassal2 >> title: 'Distribution map'; >> painting: [:view2 | >> "Simple example of a distribution map. >> Green methods are short. Orange are long. Red are very >> long" >> | view classes d packages | >> self halt. >> packages := self forumPackages. >> classes := OrderedCollection new. >> packages do: [ :p | classes addAll: p classes ]. >> d := IdentityDictionary new. >> classes do: [:aClass | aClass methods do: [:m | d >> at: m put: m getSource lineCount ] ]. >> >> view shape rectangle withoutBorder. >> view nodes: classes forEach: [ :each | >> view shape label. >> view node: each. >> view node: each forIt: [ >> view interaction action: #browse. >> view shape rectangle size: 8; >> if: [:m | (d at: m) < 5 ] >> fillColor: Color green; >> if: [:m | (d at: m) >= 5 >> and: [ (d at: m) < 25 ] ] fillColor: Color orange; >> if: [:m | (d at: m) >= 25 >> ] fillColor: Color red. >> view nodes: (each methods >> sortedAs: [:m | (d at: m) ]). >> view gridLayout gapSize: 1 ]. >> view verticalLineLayout ]. >> >> view gridLayout] > >

Sept. 15, 2014