September 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Strange behavior in Pharo 3.0

by Sven Van Caekenberghe

SequenceableCollection is abstract. Collection methods select: #isSubclassResponsibility. => {Collection>>#add:. Collection>>#do:. Collection>>#remove:ifAbsent:} The inspector probably fails because it cannot enumerate the collection. But I haven't actually tried your code. On 15 Sep 2014, at 23:12, jdelgado(a)lsi.upc.edu wrote: > Hi, > > A student of mine has accidentaly found something interesting that may be already reported, but I do not have time to check. > > The thing is simple: > > 1) Create a class with accessors for f. > > SequenceableCollection subclass: #Foo > instanceVariableNames: 'f' > classVariableNames: '' > category: 'Varios' > > 2) Foo class >> new: d > ^self new f: (Array new: d*d) > > 3) Go to Workspace and inspect the following code > > | m | > m := Foo new: 2 > > And Pharo crashes. Always crashes. I am using "Pharo 3.0 3" on OS X 10.6.8. I am pretty sure it is not a Smalltalk error since it works ok in Squeak and VisualWorks. > > So, is this a known issue? > > Bests, > > Jordi > >

Sept. 15, 2014

Strange behavior in Pharo 3.0

by jdelgado＠lsi.upc.edu

Hi, A student of mine has accidentaly found something interesting that may be already reported, but I do not have time to check. The thing is simple: 1) Create a class with accessors for f. SequenceableCollection subclass: #Foo Â Â Â instanceVariableNames: 'f' Â Â Â classVariableNames: '' Â Â Â category: 'Varios' 2) Foo class >> new: d Â Â Â ^self new f: (Array new: d*d) 3) Go to Workspace and inspect the following code Â Â Â Â Â Â | m | Â Â Â Â Â Â Â m := Foo new: 2 And Pharo crashes. Always crashes. I am using "Pharo 3.0 3" on OS X 10.6.8. I am pretty sure it is not a Smalltalk error since it works ok in Squeak and VisualWorks. So, is this a known issue? Bests, Jordi

Sept. 15, 2014

Re: [Pharo-dev] [squeak-dev] re: The Dilemma: Building a Futuristic GUI for Ephestos

by Eliot Miranda

Hi Craig, On Mon, Sep 15, 2014 at 1:40 PM, Craig Latta <craig(a)netjam.org> wrote: > > > I don't think anybody ever even reported trying [Ffenestri]. > > I did; it worked. And I just said so again a few messages ago. Hm. > OK. It opens windows. But a snippet in a workspace can do that. It does not constitute a replacement for the current window system though does it? But Vassili's work can be. We had it in production at customer sites. We could use it for development. It was complete, in the sense that one could open arbitrary system windows as native windows, switch them back to "virtual" windows, snapshot etc and everything would keep working. That's "working". With great respect to Tim and John, their work in Ffenestri is not the same thing, is it? By the same criteria I don't think what Qwaq did constituted a real system; it allowed the login WIndow to be displayed natively, but it didn't support development tools and it certainly didn't support snapshot or dynamic switching. Being critical is not being insulting. It's merely being objective. At least I hope I'm being objective and not insulting anyone. It is not my intent. -- best, Eliot

Sept. 15, 2014

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

by Tudor Girba

You mean like this: http://www.humane-assessment.com/blog/rethinking-compilation-notifications-… ? Doru On Mon, Sep 15, 2014 at 9:48 PM, stepharo <stepharo(a)free.fr> wrote: > > On 15/9/14 17:17, Esteban A. Maringolo wrote: > >> 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. >> > > me too we will get there. > > > >> :) >> >> >> 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] >>>> >>> >>> >> > > -- www.tudorgirba.com "Every thing has its own flow"

Sept. 15, 2014

Pragmas/Annotations for classes

by Torsten Bergmann

Currently only methods support pragmas in Pharo. Therefore we already had a discussion about "Pragmas/Annotations for classes". See http://forum.world.st/Pragmas-Annotations-for-classes-td2282310.html To summarize: it would be helpfull to have them (and with them also get rid of workarounds like specific conventions, abusing class comments, etc.). At that time it was not possible to add an iVar to Class, but this issue was solved already: https://pharo.fogbugz.com/f/cases/11596/Adding-an-iVar-to-class-Class-gives… Must admit I havent tested in latest Pharo 4 if this is still working. After we now have slots and other nice extensions in Pharo again my basic question: what about having "annotations" for a class in Pharo. I think we will find enough use cases on annotating a class with someting useful. Even a category or a comment could just be an annotation. Is there interest to have such a change for Pharo4 or are there reasons to abandon such an idea. I guess such a change could not be provided with a simple slice. Any thoughts/decisions? Thanks T.

Sept. 15, 2014

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

by stepharo

On 15/9/14 17:17, Esteban A. Maringolo wrote: > 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. me too we will get there. > > :) > > > 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

Re: [Pharo-dev] The Dilemma: Building a Futuristic GUI for Ephestos

by Eliot Miranda

On Mon, Sep 15, 2014 at 12:31 PM, Craig Latta <craig(a)netjam.org> wrote: > > > ...one real problem with the Squeak/Pharo UI is the lack of native > > windows. There is an old project Graphics-External-Ffenestri but > > AFAICT it isn't being used. > > I'm using it, on Mac OS so far (Windows and Ubuntu Linux are the > other host platforms I care about at the moment). > > > But there /is/ a really good prototype of a native window system > > above Squeak done by Vassili Bykov in Newspeak. > > Hoooold on there... :) Does this mean that Vassili tried Ffenestri > and found it unusable? If so, why? Details, please. > I don't want to talk for Vassili, but he had done the prototype for Pollock, the new window system for VW that was squandered by Cincom management. In this he architected full conversion between native and non-native windows, both dynamically and over snapshot. So when he came to implement the GUI for Newspeak he used that experience. I don't see the same architectural support in Graphics-External-Ffenestri it doesn't even support snapshot and resume on the same window system. Here's the relevant extract from HostWIndowProxy's class comment: "This is a proxy for a Host OS window and as such is considered a disposable item. When an image is restarted the client must recreate suitable instances from the information they hold." So I expect Vassili didn't even think of using it. Vassili's work doesn't need any VM support beyond the ability to ask the VM to /not/ respond to GUI events. It is based on the FFI and uses callbacks to receive events. In any case Vassili's work is the best candidate that I've ever seen for a proper native windows integration for Smalltalk systems that ave a history of non-native windows. thanks, > > -C > > -- > Craig Latta > netjam.org > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > > > -- best, Eliot

Sept. 15, 2014

Re: [Pharo-dev] The Dilemma: Building a Futuristic GUI for Ephestos

by Craig Latta

> ...one real problem with the Squeak/Pharo UI is the lack of native > windows. There is an old project Graphics-External-Ffenestri but > AFAICT it isn't being used. I'm using it, on Mac OS so far (Windows and Ubuntu Linux are the other host platforms I care about at the moment). > But there /is/ a really good prototype of a native window system > above Squeak done by Vassili Bykov in Newspeak. Hoooold on there... :) Does this mean that Vassili tried Ffenestri and found it unusable? If so, why? Details, please. thanks, -C -- Craig Latta netjam.org +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)

Sept. 15, 2014

Re: [Pharo-dev] #doSemanticAnalysisIn: error

by ClÃ©ment Bera

I have the issue too from time to time. I don't know where it comes from. If it comes form missing sources, it may be because some blocks have no sources even when the sources are presents (we tracked them down with Marcus but we don't know from where they come from). A solution is to use the OpalDecompiler instead of "self methodWithoutSources". 2014-09-15 20:47 GMT+02:00 Damien Cassou <damien.cassou(a)gmail.com>: > On Mon, Sep 15, 2014 at 8:01 PM, Esteban A. Maringolo > <emaringolo(a)gmail.com> wrote: > > Why is this? Is it a know bug? > > > is it possible that you don't have the source code of your image? Both > the .changes and .sources must be available > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill > >

Sept. 15, 2014

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

by Thierry Goubier

Hi Eliot, Le 15/09/2014 18:23, Eliot Miranda a Ã©crit : > Hi All, > > On Mon, Sep 15, 2014 at 6:01 AM, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > > 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. I certainly appreciate how much we own to your work on Cog. I wouldn't have come back to Squeak/Pharo without it (not after going through the Squeak VM when Ian Piumarta was taking care of it), and I'm thrilled by the performance goals you're targetting. This is great! At the same time, I do use that C/LLVM today for automatic vectorization, GPU support, automatic parallelisation for CPUs with over a thousand cores, compiling for exotic embedded platforms... That work I have to do for R (or Python) I'd also like to explore it with Pharo and for that, FFI or NativeBoost have their uses. Including the fact that I can run experiments proving or disproving certain techniques/attempts without bothering Cog development until it is proven it is worth the inclusion :) > 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. You have a point :) VM development is hard, and is vital for Squeak/Pharo. > > 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> You didn't announce the last one or I missed it? Regards, Thierry

Sept. 15, 2014