- Pharo-dev - lists.pharo.org

RBSmalllintContext>>primitiveComputerLiterals
by Ben Coman Dec. 8, 2014

Dec. 8, 2014

I just noticed RBSmalllintContext>>primitiveComputerLiterals doesn't seem to follow the typical pattern for that naming convention. Without digging to really understand it, I just wondered if it maybe should be called #computeLiteralsForPrimitive, or #basicComputerLiterals, or something else... cheers -ben

3 3

From IRC: is glorp dead?
by Max Leske Dec. 8, 2014

Dec. 8, 2014

>From the IRC: LudicrousMango: Hi can anyone tell me is Glorp dead? I was trying to evaluate pharo as a replacement for an existing rails project, but I can't even find a way of connecting to my postgresql database. LudicrousMango: can someone help point me in the right direction. The Enterprise book leaves the setup part of glorp blank. LudicrousMango: and the glorp.org site has expired maxleske: LudicrousMango: good question. Iâll forward it to the dev mailing list Cheers, Max

5 7

Morphic3 and BPG
by Torsten Bergmann Dec. 8, 2014

Dec. 8, 2014

Hi, Found the below one somewhere on the internet today. To the graphic gurus: any comments regarding Morphic 3 or the new BPG format in the context of Pharo? Thx T. ------------------------------------------------------------------------------------------------- CUIS Smalltalk-80 GUI algorithm now available in C, JS! Maybe, some people haven't yet noticed, that CUIS Smalltalk GUI uses a completely different antialiasing algorithm. Excellent MORPHIC-3, antialiased: http://www.jvuletich.org/Morphic3/Morphic3-200911.html The filter is named after Cornelius Lanczos (Hungarian pronunciation: [ ËlaËntsoÊ]) Lanczos resampling or Lanczos filter is a mathematical formula used to smoothly interpolate the value of a digital signal between its samples. So, no more artefacts! Resulting in a 3x higher compression without significant loss of image quality. Isn't that just wonderful? Here Fabrice Bellard's implementation: http://bellard.org/bpg/lena.html -------------------------------------------------------------------------------------------------

1 0

Monticello and Fuel
by Thierry Goubier Dec. 8, 2014

Dec. 8, 2014

Hi all, I'm just wondering. Would it work to have a package format based on Fuel? Would that make loading faster? Does it already exist? Thanks, Thierry

10 25

[pharo-project/pharo-core] 172f0e: 40403
by GitHub Dec. 7, 2014

Dec. 7, 2014

Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: 172f0e542d76844088db11e23938b50b3572ccd5 https://github.com/pharo-project/pharo-core/commit/172f0e542d76844088db11e2… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-12-07 (Sun, 07 Dec 2014) Changed paths: M Morphic-Widgets-List.package/TreeListMorph.class/instance/private/addSubmorphsAfter_fromCollection_allowSorting_.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script403.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40403.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 40403 12027 Merge is incredibly slow with Polymorph difference tools, and unusable without https://pharo.fogbugz.com/f/cases/12027 http://files.pharo.org/image/40/40403.zip

1 0

[pharo-project/pharo-core]
by GitHub Dec. 7, 2014

Dec. 7, 2014

Branch: refs/tags/40403 Home: https://github.com/pharo-project/pharo-core

1 0

Re: [Pharo-dev] [Esug-list] [ann] gtspotter: a moldable interface for spotting objects
by Tudor Girba Dec. 7, 2014

Dec. 7, 2014

:) I know how this feels. On the other hand, with this one we target 15 minutes (= the coffee break) :) Doru On Sun, Dec 7, 2014 at 4:20 PM, stephane ducasse <stephane.ducasse(a)gmail.com > wrote: > > Hi, > > This is indeed a significant challenge. Until that point we need a couple > of more features, of which the most important is the preview for the > selected object. This will come and then we can consider what we can do > with it. > > But, in the meantime, there are a lot of use cases nobody ever considered > exactly because there was no easy way to consider them. Like finding all > the methods from CodeHolder* that are annotated with <systemsettings>. Or > like searching a Person in a Agenda model that someone develops. > > The cool thing is that you can program this yourself :). > > > :) > Donât get me tempted :) > > I have boring tasks to do :) > > Stef > > -- www.tudorgirba.com "Every thing has its own flow"

1 0

Re: [Pharo-dev] [Esug-list] [ann] gtspotter: a moldable interface for spotting objects
by Tudor Girba Dec. 7, 2014

Dec. 7, 2014

Hi, This is indeed a significant challenge. Until that point we need a couple of more features, of which the most important is the preview for the selected object. This will come and then we can consider what we can do with it. But, in the meantime, there are a lot of use cases nobody ever considered exactly because there was no easy way to consider them. Like finding all the methods from CodeHolder* that are annotated with <systemsettings>. Or like searching a Person in a Agenda model that someone develops. The cool thing is that you can program this yourself :). Cheers, Doru On Sun, Dec 7, 2014 at 4:05 PM, stephane ducasse <stephane.ducasse(a)gmail.com > wrote: > > On 07 Dec 2014, at 06:56, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Thanks, Stef. > > On Sun, Dec 7, 2014 at 2:35 PM, stephane ducasse < > stephane.ducasse(a)gmail.com> wrote: > >> Truly excellent! >> I have to try :) >> I read the blog (I love the marketing efforts and the documentation >> effort) :) >> Now do you a shortcut for finding a >> - senders? >> > - a specific method of a class? >> > > This first incarnation of the interface is meant to replace the top level > search because that was easier. There is more to come, and we definitely > will get to replace the senders, and integrate it even deeper in the > workflow > > > > A challenge that I would like to propose to the GTteam is the following > one: > > Often when I change code (for example, change the API of menus and want to > make it clean) > I look at all the senders and sender of senders and implementors and > senders â¦. > What I do is that I stack the browser in the stack where the top are the > leaves that I should treat and the next elements are the user of the > leavesâ¦. > Then what I do I have a physical stack of senders/implementors and I start > fixing the top of the stack > and I pop. > > So the old Omnibrowser based senders/implementors nevers worked to me > because I could never understand > what I was browsing (senders or implementers and where I was in the stack > or search tree). > > So my challenge is > - how can we support mixing senders and implementors taxes (not mixing the > two) > - how can we support the navigation with the tree of such tasks. > > Iâm not sure that it should be in GTSpotter and many having a tree > structure could help. > Stef > > > > >> Last time I found myself looking for the sender of x but only inside the >> implementor of y. >> and of course I wanted to refactored them. And the default message >> browser is not parametrized via an environment :_ >> > > Exactly. This problem exists in any IDE I know. > > > Really? Iâm surprised because it seems so obvious (if we had a couple > million dollarsâ¦ but we have cool guys) > > Doru > > >> Stef >> >> On 07 Dec 2014, at 05:14, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> Hi, >> >> Alex Syrel, Andrei Chis and I are happy to announce a new addition to the >> Glamorous Toolkit: >> GTSpotter, a novel interface for spotting objects. >> >> GTSpotter has two goals: >> - Provide a uniform yet moldable interface that can work on any object, >> and >> - Handle searching through arbitrary levels of object nesting. >> >> We think this will have a significant impact on the development workflow >> in Pharo. >> >> Here is a couple of screenshots: >> <gtspotter-packages-classes.png> <gtspotter-dive-class-method-sender.png> >> <gtspotter-playground.png> >> >> >> A trailer is available here: >> https://www.youtube.com/watch?v=PhSmjR3NOlU >> >> A detailed description is available here: >> http://www.humane-assessment.com/blog/introducing-gtspotter >> >> It works already in Pharo 3.0 and can be played with by following the >> instructions from: >> http://gt.moosetechnology.org >> >> Please let us know what you think. >> >> Enjoy, >> The Glamorous Team >> _______________________________________________ >> Esug-list mailing list >> Esug-list(a)lists.esug.org >> http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"

1 0

Re: [Pharo-dev] [Esug-list] [ann] gtspotter: a moldable interface for spotting objects
by Tudor Girba Dec. 7, 2014

Dec. 7, 2014

Thanks, Stef. On Sun, Dec 7, 2014 at 2:35 PM, stephane ducasse <stephane.ducasse(a)gmail.com > wrote: > Truly excellent! > I have to try :) > I read the blog (I love the marketing efforts and the documentation > effort) :) > Now do you a shortcut for finding a > - senders? > - a specific method of a class? > This first incarnation of the interface is meant to replace the top level search because that was easier. There is more to come, and we definitely will get to replace the senders, and integrate it even deeper in the workflow > Last time I found myself looking for the sender of x but only inside the > implementor of y. > and of course I wanted to refactored them. And the default message browser > is not parametrized via an environment :_ > Exactly. This problem exists in any IDE I know. Doru > Stef > > On 07 Dec 2014, at 05:14, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > Alex Syrel, Andrei Chis and I are happy to announce a new addition to the > Glamorous Toolkit: > GTSpotter, a novel interface for spotting objects. > > GTSpotter has two goals: > - Provide a uniform yet moldable interface that can work on any object, and > - Handle searching through arbitrary levels of object nesting. > > We think this will have a significant impact on the development workflow > in Pharo. > > Here is a couple of screenshots: > <gtspotter-packages-classes.png> <gtspotter-dive-class-method-sender.png> > <gtspotter-playground.png> > > > A trailer is available here: > https://www.youtube.com/watch?v=PhSmjR3NOlU > > A detailed description is available here: > http://www.humane-assessment.com/blog/introducing-gtspotter > > It works already in Pharo 3.0 and can be played with by following the > instructions from: > http://gt.moosetechnology.org > > Please let us know what you think. > > Enjoy, > The Glamorous Team > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org > > > -- www.tudorgirba.com "Every thing has its own flow"

1 0

Re: [Pharo-dev] [Vm-dev] [ANN] ARM Stack VMs available
by Eliot Miranda Dec. 7, 2014

Dec. 7, 2014

Hi Juan, On Dec 5, 2014, at 4:56 AM, "J. Vuletich (mail lists)" <juanlists(a)jvuletich.org> wrote: > Hi Folks, > > The Squeak process scheduler usually preempts a process only by another one of higher priority. And when the scheduler is ready to go back at the lower priority, it will always resume the same process that was last suspended. The only way for two or more processes of the same priority to share the processor is when the running process calls #wait or #yield. No. According to the blue book preempting sends the preempted process to the back if its run queue so preempting forces a yield. Obviously this is wrong, but that's the way it was defined. The ObjectWorks & VisualWorks VMs changed this to work as you describe. When I implemented Cog I wanted to fix this but not break old code so I made it optional. The behavior is controlled by a flag in the image. You can see the flags via Smalltalk vmParameterAt: 48. Bit 2 (value 4) is set if preempting puts the preempted process at the head of its list, and hence does not yield. Here's the part of the comment from vmParameterAt: 48 various properties of the Cog VM as an integer encoding an array of bit flags. Bit 0: implies the image's Process class has threadId as its 3rd inst var (zero relative) Bit 1: on Cog VMs asks the VM to set the flag bit in interpreted methods Bit 2: if set, preempting a process puts it to the head of its run queue, not the back, i.e. preempting a process by a higher one will not cause the process to yield to others at the same priority. > This means that using shared state from several processes at the same priority (without using any locking mechanism, such as Semaphores, Monitors or critical sections) is safe, as long as the processes do #wait or #yield only when that shared state is in a consistent state. Right. > > It looks like this ARM VM is somehow not following this convention. If this was the case, the problems Ken sees are to be expected. Can you check the bit is set in the image? Thanks for raising this. It looks like the Spur images have the bit cleared. Ouch. Ah, it's not a problem of the bootstrap, its at least a problem in trunk. The bit is not set in trunk. I need to a) write some tests to test the bit and b) make sure its set in the relevant places. > > HTH, > Juan Vuletich Eliot (phone) > Quoting Douglas McPherson <djm1329(a)san.rr.com>: > >> Hi Ken, >> >>> On Nov 11, 2014, at 16:28, Ken Dickey <Ken.Dickey(a)whidbey.com> wrote: >>> >>> >>> On Sun, 9 Nov 2014 20:56:47 -0800 >>> Douglas McPherson <djm1329(a)san.rr.com> wrote: >>> >>> KenD>> >>>>> The stkspurlinuxhtARM VM, however, complains: >>>>> This interpreter (vers. 6521) cannot read image file (vers. 6505). >>>>> >>>>> I presume some conversion is required to get the image into SPUR format? >>>> Yes, the Spur VMs require a new image format. There are recent Squeak trunk images in the spur format on Eliotâs site. Iâll let Eliot and others comment about how a Cuis image might be converted. >>> >>> I tried out the Squeak SPUR image from the Cog site and everything Squeak seems fine. >>> >>> >>> There is a timing bug with Cuis redraw that shows up on both the stklinuxhtARM vm and the one you sent me earlier. >>> >>> Basically, I am using DisplayObject>>slideFrom:to:nSteps:delay: to do some animation. When multiple timer events fire during an animation it sometimes appears that the x,y redraw origin is used from the currently drawing morph's position, not 0,0. I.e. part of the redisplay is offset. [Display redraw via menu corrects the display]. >>> >>> This _only_ happens on the Samsung ARM Chromebook, never on Intel CPUs. >> >> Thanks for reporting this. Iâll try to look into it. There are definitely ARM-specific changes to support certain atomic operations, so there may be something not quite right with these. >> >> Can you suggest a method for reproducing this in Squeak? I repeatedly sent morphs to the trash (with appropriate preference set to enable the animation) but didnât see an issue. I suspect Iâm not driving it hard enough. >> >>> My life is really, really busy right now, so I have never had time to dig into this. I can redraw the display, so a workaround exists. >>> >>> [One possible resource. The Apache Portable Runtime, http://apr.apache.org/ , implements compareAndSwap and various other atomic operations across various OSs.] >> >> Thanks for the reference. It may be useful. I also found a library called Mintomic (http://preshing.com/20130505/introducing-mintomic-a-small-portable-lock-fre…) which may help. >> >>> I am happy to do quick tests, but must apologize for lack of time to dig into this. >> >> No problems, and thanks again for reporting it. >> >> >>> FYI, >>> -KenD

4 4