- Pharo-users - lists.pharo.org

Re: [Pharo-users] Happy new year 2016

by Hilaire

Thanks Stephane & al. Happy new year and success for the Pharo project! Hilaire Le 01/01/2016 16:57, stepharo a Ã©crit : > Hi Pharoers > > I want to thank all of you for making Pharo what it is becoming: a > Really Cool system and community. > > I wish you good health and a lot of business or fun in Pharo :). > > 2016 will see many changes that are planned > to name a few > - Pharo 5.0 with Spur > - Pharo 5.0 with 64 bits > - Bootstrap Pharo in production > - SDL full integration > - Git and Package validation > - A full Mooc on Pharo > - A couple of cool tutorials > And I'm sure many unexpected project and libraries... > > The consortium should continue to grow so if you are hesitating to > join please do. > > Stef > > -- Dr. Geo http://drgeo.eu http://google.com/+DrgeoEu

Jan. 1, 2016

Happy new year 2016

by stepharo

Hi Pharoers I want to thank all of you for making Pharo what it is becoming: a Really Cool system and community. I wish you good health and a lot of business or fun in Pharo :). 2016 will see many changes that are planned to name a few - Pharo 5.0 with Spur - Pharo 5.0 with 64 bits - Bootstrap Pharo in production - SDL full integration - Git and Package validation - A full Mooc on Pharo - A couple of cool tutorials And I'm sure many unexpected project and libraries... The consortium should continue to grow so if you are hesitating to join please do. Stef

Jan. 1, 2016

Re: [Pharo-users] Pharo 5: Bug in removing key combinations

by Tudor Girba

Hi, That is why I think the mechanism of categories per morph type is too complicated. Instead, I would prefer to only have instance side keybindings that can be installed during the instantiation. Cheers, Doru > On Dec 30, 2015, at 1:36 AM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2015-12-29 14:13 GMT+01:00 Johan Fabry <jfabry(a)dcc.uchile.cl>: > Thanks Nicolai for having a look! I added a bug report and notified you since you seem to be knowledgeable of the key shortcut system. > > In any case, URL to the bug report is https://pharo.fogbugz.com/f/cases/17304/Morph-removeKeyCombination-removes-… > > > I think the problem is that this morph, does not have a direct keymap. If it can not find a direct keymap, it searches > all keymap categories used by this morph and removes the shortcut for this category, and this category keymap is shared > by all RubEditingAreas. > > (I don't know if this is a bug, but I would say, the call to #removeKeyCombination: on the morph, should only remove direct keymap entries, not > those defined for the keymap category). > > If you just want to redefine some shortcuts (like in this example), it isn't necessary to remove the defined (category-shortcuts) but just > add the new ones: > > > | morph | > morph := RubScrolledTextMorph new. > > (morph textArea) > on: $s command do: [42 inspect ]; > on: $s control do: [42 inspect ]. > > morph openInWorld. > > > > >> On Dec 29, 2015, at 09:51, Nicolai Hess <nicolaihess(a)gmail.com> wrote: >> >> >> >> 2015-12-28 19:07 GMT+01:00 Johan Fabry <jfabry(a)dcc.uchile.cl>: >> Hi all, >> >> Miguel and I found a bug in removing key combinations on a morph. Now they are global, while in Pharo 4 this was not the case. >> >> I was able to reproduce this on Pharo 4 as well, I think the main difference is that Pharo 5 uses Rubric for "Workspace/Playground" AND the Browser. >> And in Pharo 4 these Tools use different Morphs. >> >> >> Consider the following code: >> >> | morph | >> morph := RubScrolledTextMorph new. >> >> (morph textArea) >> removeKeyCombination: $s command; >> removeKeyCombination: $s control; >> on: $s command do: [morph flash ]; >> on: $s control do: [morph flash ]. >> >> morph openInWorld. >> >> In the morph, cmd-s will cause a flash, as expected. However in other windows (or browsers and playgrounds least) the original shortcut is lost, only a s character is added to the text field. >> >> For me, the "morph flash" wasn't working on the RubRricTextMorph, unitil I opened a Transcript and enabled KeyLog setDebug. Only after this the morph was actually flashing (or the flashing wasn't visible?). >> >> >> I did not see it on fogbugz so I would like to announce it here before I open a case, in case (heh) I missed it. So the question: is this a known bug? >> >> No, I think this bug is not yet reported. >> >> >> >> ---> Save our in-boxes! http://emailcharter.org <--- >> >> Johan Fabry - http://pleiad.cl/~jfabry >> PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > > -- www.tudorgirba.com www.feenk.com "It's not what we do that matters most, it's how we do it."

Dec. 30, 2015

Re: [Pharo-users] Pharo 5: Bug in removing key combinations

by Johan Fabry

Great, that solves the problem I was having. Thanks a lot! > On Dec 29, 2015, at 20:36, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > If you just want to redefine some shortcuts (like in this example), it isn't necessary to remove the defined (category-shortcuts) but just > add the new ones: > > > | morph | > morph := RubScrolledTextMorph new. > > (morph textArea) > on: $s command do: [42 inspect ]; > on: $s control do: [42 inspect ]. > > morph openInWorld. ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

Dec. 30, 2015

Re: [Pharo-users] Determining if a Process is waiting on a Semaphore

by Guillermo Polito

A bit more on that: Processor activeProcess suspendingList. => nil âAn active process has nil as a list" Processor activeProcess isSuspended. => true?? p := [ ] forkAt: 30. p suspendingList. => âthe list where it is waiting ready to run" p isSuspended. => false? s := Semaphore new. p := ([ s wait ] forkAt: 50). p suspendingList. => âthe semaphore where it is waiting to be unsuspended, since a semaphore is a list" p isSuspended. => false? It is evident that a suspended process has the list where it is waiting, and the active process has nil. Then, I think the problem is that isSuspended is wrong. isSuspended ^myList isNil or: [ myList isEmpty ] When it should be maybe isSuspended ^myList notNil Am I wrong? Then, to actually answer your question, you can check if you are waiting in a semaphore or not, you can compare that the suspendingList is = to the semaphore. Of course we should also revise the API ^^. s := Semaphore new. p := ([ s wait ] forkAt: 50). p suspendingList == s Guille > On 30 dic 2015, at 5:35 a.m., Ben Coman <btc(a)openinworld.com> wrote: > > Looking at at the primitive comment in... > Semaphore>>wait > "excessSignals>0 > ifTrue: [excessSignals := excessSignals-1] > ifFalse: [self addLastLink: Processor activeProcess suspend]" > > I expected/hoped the following... > Transcript clear. > s := Semaphore new. > p := [ Transcript crShow: '1'. s wait. Transcript crShow: '2' ] forkAt: 50. > Transcript crShow: p isSuspended. > s signal. > > would produce > 1 > true > 2 > > but I get > 1 > false > 2 > > How do I determine from another thread if a Process is waiting on a > Semaphore, or even better, waiting on a particular semaphore? > > cheers -ben >

Dec. 30, 2015

Versionner and package dependencies

by Ferlicot D. Cyril

Hi, I wanted to use versionner to manage some existing configurations but in one of these configuration there is some dependencies on packages that have no project. For example in the baseline there is: spec package: 'Glamour-EyeSee-Presentations' with: [ spec requires: #('EyeSee'). spec repository: 'http://smalltalkhub.com/mc/Moose/Glamour/main' ]. But in versionner I can only add a project as dependency. Is there a way to do such a thing or is it a future feature of versionner? -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Dec. 30, 2015

Determining if a Process is waiting on a Semaphore

by Ben Coman

Looking at at the primitive comment in... Semaphore>>wait "excessSignals>0 ifTrue: [excessSignals := excessSignals-1] ifFalse: [self addLastLink: Processor activeProcess suspend]" I expected/hoped the following... Transcript clear. s := Semaphore new. p := [ Transcript crShow: '1'. s wait. Transcript crShow: '2' ] forkAt: 50. Transcript crShow: p isSuspended. s signal. would produce 1 true 2 but I get 1 false 2 How do I determine from another thread if a Process is waiting on a Semaphore, or even better, waiting on a particular semaphore? cheers -ben

Dec. 30, 2015

Re: [Pharo-users] Dolphin Smalltalk open-sourced...

by Ben Coman

Really interesting news. I was curious for some history and the reason for the open sourcing, since back in 2007 Andy Bower said [1] "It is with great regret and more than a touch of sadness that I have to announce that Blair and I have made the decision to stop selling and developing Dolphin Smalltalk. We will continue to distribute the free version of Dolphin X6 indefinitely but, as from today, we will not be selling the Professional version. [...] There will no doubt be a number of you who would suggest that we Open Source Dolphin. Of course, you are free harbour such opinions and to discuss the idea on the newsgroup but please do not expect us to be persuaded. It simply will not happen! Both Blair and I dislike the Open Source movement intensely and we would rather see Dolphin gradually disappear into the sands of time than instantly lose all commercial value in one fell swoop." but then even Microsoft has significantly changed its stance on open source [2]. It seems there was initial discussion in Feb 2014 of pledges to open source Dolphin [3], followed by ObjectArts proposal July 2014 for $10-$15k crowd-funding [4], but in the end it seems they bypassed that and Dec 2014 went straight to an MIT release [5]. I don't think we should take this as an opportunity to simply raid their coffers and ideally aim there would be some mutual beneficial to reward their move to open source. As I understand it, Dolphin is Microsoft only but using 32-bit Win32 API rather than .NET, although it can run under Wine[6], so Pharo has some advantages there - particularly considering the mobile arena. I doubt its practical to merge the two products since I *guess* much of Dolphin's attractiveness is its tight coupling to Microsoft, but since they've got this "ph" in their name, I can't help imagining a product with 64-bit Cog-Spur-Sista + lower level Pharo infrastructure + Dolphin GUI - that might be named "Dolpharo" ;) cheers -ben [1] http://forum.world.st/Terrible-News-Dolphin-is-Dying-td1408648.html [2] https://redmondmag.com/articles/2015/09/01/changing--dna.aspx [3] https://groups.google.com/forum/#!searchin/comp.lang.smalltalk.dolphin/open… [4] https://groups.google.com/forum/#!msg/comp.lang.smalltalk.dolphin/0EIhRyLBw… [5] https://groups.google.com/d/msg/comp.lang.smalltalk.dolphin/YOxRJ_Q9BKo/E8W… [6] http://www.object-arts.com/blog/files/904294e27cec4b8dff96422f3197f603-5.ht… On Tue, Dec 29, 2015 at 11:26 PM, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > I dunno if they will be any impact on Pharo, because having a software > open-source is great, but you also need > a benevolent dictator and a community to give a direction ;-) > > If the licence is MIT, this is great, because Pharo could reuse some > parts of Dolphin Smalltalk without any problems. > > Regards, > > On Tue, Dec 29, 2015 at 12:57 PM, SaÅ¡a JaniÅ¡ka <gour(a)atmarama.com> wrote: >> ...with MIT license, so I wonder if that will have some impact on >> further development of Pharo? >> >> Iirc, Dolphin can produce stand-alone Windows executable, but maybe >> something else can be utilized as well? >> >> Here is the link with: http://object-arts.com/gettingstarted.html >> >> Sincerely, >> Gour >> >> -- >> The humble sages, by virtue of true knowledge, see with equal >> vision a learned and gentle brÄhmana, a cow, an elephant, a dog >> and a dog-eater. >> >> >> >> >> > > > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ >

Dec. 30, 2015

Re: [Pharo-users] Pharo 5: Bug in removing key combinations

by Nicolai Hess

2015-12-29 14:13 GMT+01:00 Johan Fabry <jfabry(a)dcc.uchile.cl>: > Thanks Nicolai for having a look! I added a bug report and notified you > since you seem to be knowledgeable of the key shortcut system. > > In any case, URL to the bug report is > https://pharo.fogbugz.com/f/cases/17304/Morph-removeKeyCombination-removes-… > > I think the problem is that this morph, does not have a direct keymap. If it can not find a direct keymap, it searches all keymap categories used by this morph and removes the shortcut for this category, and this category keymap is shared by all RubEditingAreas. (I don't know if this is a bug, but I would say, the call to #removeKeyCombination: on the morph, should only remove direct keymap entries, not those defined for the keymap category). If you just want to redefine some shortcuts (like in this example), it isn't necessary to remove the defined (category-shortcuts) but just add the new ones: | morph | morph := RubScrolledTextMorph new. (morph textArea) on: $s command do: [42 inspect ]; on: $s control do: [42 inspect ]. morph openInWorld. > On Dec 29, 2015, at 09:51, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > > > > 2015-12-28 19:07 GMT+01:00 Johan Fabry <jfabry(a)dcc.uchile.cl>: > >> Hi all, >> >> Miguel and I found a bug in removing key combinations on a morph. Now >> they are global, while in Pharo 4 this was not the case. > > > I was able to reproduce this on Pharo 4 as well, I think the main > difference is that Pharo 5 uses Rubric for "Workspace/Playground" AND the > Browser. > And in Pharo 4 these Tools use different Morphs. > > > >> Consider the following code: >> >> | morph | >> morph := RubScrolledTextMorph new. >> >> (morph textArea) >> removeKeyCombination: $s command; >> removeKeyCombination: $s control; >> on: $s command do: [morph flash ]; >> on: $s control do: [morph flash ]. >> >> morph openInWorld. >> >> In the morph, cmd-s will cause a flash, as expected. However in other >> windows (or browsers and playgrounds least) the original shortcut is lost, >> only a s character is added to the text field. >> > > For me, the "morph flash" wasn't working on the RubRricTextMorph, unitil I > opened a Transcript and enabled KeyLog setDebug. Only after this the morph > was actually flashing (or the flashing wasn't visible?). > > >> >> I did not see it on fogbugz so I would like to announce it here before I >> open a case, in case (heh) I missed it. So the question: is this a known >> bug? >> > > No, I think this bug is not yet reported. > > >> >> >> ---> Save our in-boxes! http://emailcharter.org <--- >> >> Johan Fabry - http://pleiad.cl/~jfabry >> PLEIAD and RyCh labs - Computer Science Department (DCC) - University >> of Chile > > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD and RyCh labs - Computer Science Department (DCC) - University > of Chile > >

Dec. 29, 2015

Re: [Pharo-users] Block that doesn't leak memory

by webwarrior

I've looked at implementation of cleanCopy. It removes sender, but my problem is with receiver. However I wrote similar set of methods that also set receiver to nil. Seems to work fine, in debugger such blocks are seen as defined in DoIt. On 29.12.2015 3:42, Mariano Martinez Peck [via Smalltalk] wrote: > This is halt related, but you can see how Fuel checks wether the closure > is "clean" and if true, it serializes a pruned version of it so that to > avoid a whole stack. See BlockClosure >> fuelAccept: > > fuelAccept: aGeneralMapper > > ^ self *shouldBeSubstitutedByCleanCopy* > "The 'onRecursionDo:' is just to avoid an infinitive loop for the > substitution. The cleanCopy MUST be a clean copy so it can be serialized > normally" > ifTrue: [ aGeneralMapper visitSubstitution: self by: *self cleanCopy > *onRecursionDo: [ aGeneralMapper visitVariableObject: self ] ] > ifFalse: [ aGeneralMapper visitVariableObject: self ] -- View this message in context: http://forum.world.st/Blocks-that-don-t-leak-memory-tp4868529p4868838.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Dec. 29, 2015