- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Adapting the launcher to Spur VM

by Esteban A. Maringolo

Was this fixed? I downloaded the latest 5.0 image and also the Moose gttoolkit5 images, and I can't start them, the launcher closes without any further notification. My previous 5.0 image (from Dec/10th 2015) starts normally. It would be great to have a two lines list of the images, one with the name/description, and other subline with the image version and vm version. :) Where can I get the source of the launcher itself? Regards! Esteban A. Maringolo 2015-12-17 18:11 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: > On 17/12/15 22:04, David T. Lewis wrote: >>> >>> On 17-12-15 18:21, Eliot Miranda wrote: >>>> >>>> Hi Stephan, >>>> >>>> I love you too ;-). Just in case you weren't aware David Lewis' >>>> ImageFormat package on http://source.squeak.org/VMMaker contains the >>>> "official" approach to image version ids and will provide you with "the >>>> official way" (tm) to test for a Spur image, including 64-bits. >>> >>> >>> Ah, there is a lot more to do than testing for 6505, I see. >>> I suspect ImageFormat needs an update, the last version is from 2011 and >>> Spur is suspiciously missing. I'll add that instead. >>> >>> Stephan >>> >> >> Make sure you got the latest version from the repository, it should be >> fully up to date, including the image format info for the 64-bit Spur >> image. > > > Ah, that is not the same as squeaksource.com ... > My mistake > > Stephan > >

Jan. 8, 2016

Re: [Pharo-dev] GTDebugger (case 17341 Integrate GTools version 3.3)

by Andrei Chis

Hi Nicolai, Thanks for the feedback. Some issues I'll manage to fix until we integrate. For those that I do not manage please open bug reports. On Thu, Jan 7, 2016 at 9:13 PM, Nicolai Hess <nicolaihess(a)gmail.com> wrote: > Some feedback on GTDebugger > > - The inspector pane is great, we can inspect, evaluate code, and easily > show/ inspect the code (for thisContext). > although the evaluator pane has a bad text mode (for the thisContext). > Can you give me more details? Maybe it's obvious but I'm missing what's wrong :) Cheers, Andrei > - I think the buttons are too small and the icon for "stop over" is > misleading, it looks like a "step out" > - the shortcuts (neither ctrl+t nor cmd+t) aren't working > - I find it totally annoying and useless that the context pane inspector > scrolls away if you select a value in > the rightmost pane. The context inspector should be fixed. > - I really miss the "List Methods using 'varname'/List Methods storing > into 'varname' > - the stacklist entry for block closures prints the block closure code, > this is confusing (too much text for such a small widget). > > nicolai >

Jan. 8, 2016

Re: [Pharo-dev] [Pharo-users] gtdebugger in pharo 5.0

by Alexandre Bergel

This is an excellent news! I have been waiting for that for long! go go go! Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > On Jan 8, 2016, at 8:07 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > We are about to integrate in Pharo a new member of the Glamorous Toolkit: the GTDebugger. As this is a significant change that might affect your workflow, here is some background information to help you deal with the change. > > First, you should know that the change is not irreversible and it is easily possible to disabled the new debugger through a setting. However, please do take the time to provide us feedback if something does not work out for you. We want to know what can be improved and we try to react as fast as we can. > > A practical change comes from the fact that the variables are manipulated through a GTInspector, which makes it cheaper to maintain in the longer run. > > While the first thing that will capture the attention is the default generic interface, the real power comes from the moldable nature of the debugger. Like all other GT tools, GTDebugger is also moldable by design. This means that we can construct custom debuggers for specific libraries at small costs (often measured in a couple of hundred lines of code). > > For example, the core configuration includes also the SUnit and the bytecode debugger. These are around 150 lines of code. Here is how the bytecode debugger looks like: > > <bytecode.png> > > You can find more information in an introductory overview blog post that also includes some links for further reading: > http://www.humane-assessment.com/blog/gtdebugger-in-pharo/ <http://www.humane-assessment.com/blog/gtdebugger-in-pharo/> > > Please let us know what you think. > > Cheers, > Doru > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > www.feenk.com > > "What is more important: To be happy, or to make happy?" >

Jan. 8, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Ben Coman

Long standing Case 5959 "Process suspension and Semaphore clash" seems related... https://pharo.fogbugz.com/default.asp?5959 cheers -ben On Fri, Jan 8, 2016 at 10:45 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > I not understand. Is you code is working for you? > > This test return nil on my image: > > sema := Semaphore new. > p:= [ sema waitIfCurtailed: [ r := p suspendingList ] ] fork. > 1 seconds wait. > p terminate2. "your implementation" > r. > > > And what I try to said is as soon as suspend called on waiting process > semaphore is not anymore on it suspendingList. > > > > 2016-01-08 15:35 GMT+01:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: >> >> >> On 08 Jan 2016, at 3:24 , Denis Kudriashov <dionisiydk(a)gmail.com> wrote: >> >> >> 2016-01-08 15:17 GMT+01:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: >>> >>> Which is why in terminate I do >>> myList := self suspend. >>> >>> So the semaphore *should* still be the suspendingList, just without the >>> process actually on the list... >> >> >> I just test it in workspace. >> >> sema := Semaphore new. >> p := [sema wait] fork. >> p suspend. >> p suspendingList == nil >> >> sema asArray isEmpty >> >> >> >> Of course, that's something entirely different... >> if you do what I actually do in the modified terminate; >> sema := Semaphore new. >> p := [sema wait ] newProcess. >> p resume. >> 1 second wait. >> list := p suspend. >> "this list is (re)assigned to myList in terminate" >> list == nil >> list == sema >> >> You should get different answers. >> >> Cheers, >> Henry >> >> >

Jan. 8, 2016

Re: [Pharo-dev] Setup Locale for Italy country

by Sven Van Caekenberghe

But even so, there is totally no provision in the image to magically change for example date formatting or parsing based on (one global default) locale, let alone the decimal or thousands separators. One could even argue whether that would be a good idea or not. The alternative would be for you to use the appropriate formatters/parsers where you produce/consume user visible text. There are certainly provisions for doing that, as well as several external frameworks that can help. > On 08 Jan 2016, at 15:39, Max Leske <maxleske(a)gmail.com> wrote: > > Wow! Locale seems to be seriously broken: variables have not accessors, primitives have not senders... > > It seems that the primitives can be used without problems to access the locale properties of the host OS but it seems that itâs not possible to switch the locale. > > >> On 08 Jan 2016, at 12:17, Trussardi Dario Romano <dario.trussardi(a)tiscali.it> wrote: >> >> Ciao, >> >> i work with Pharo4.0 Latest update: #40625 >> >> Now i need to setup the system to manage the Italy country >> >> - decimalSymbol ( , ) >> - currencySymbol ( â¬ ) >> >> -dateFormat dd-MM-yyyy HH:mm >> >> How i can do it ? >> >> What is the Pharo system status about localization ? >> >> The: Locale current answer aLocale instance >> >> with id set to it-It >> >> but with all variables set to nil. >> >> >> Thanks for any considerations, >> >> Dario > >

Jan. 8, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Denis Kudriashov

I not understand. Is you code is working for you? This test return nil on my image: sema := Semaphore new. p:= [ sema waitIfCurtailed: [ r := p suspendingList ] ] fork. 1 seconds wait. p terminate2. "your implementation" r. And what I try to said is as soon as suspend called on waiting process semaphore is not anymore on it suspendingList. 2016-01-08 15:35 GMT+01:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > > On 08 Jan 2016, at 3:24 , Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-01-08 15:17 GMT+01:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > >> Which is why in terminate I do >> myList := self suspend. >> >> So the semaphore *should* still be the suspendingList, just without the >> process actually on the list... >> > > I just test it in workspace. > > sema := Semaphore new. > p := [sema wait] fork. > p suspend. > p suspendingList == nil > > sema asArray isEmpty > > > > Of course, that's something entirely different... > if you do what I actually do in the modified terminate; > sema := Semaphore new. > p := [sema wait ] newProcess. > p resume. > 1 second wait. > list := p suspend. > "this list is (re)assigned to myList in terminate" > list == nil > list == sema > > You should get different answers. > > Cheers, > Henry > > >

Jan. 8, 2016

Re: [Pharo-dev] Setup Locale for Italy country

by Max Leske

Wow! Locale seems to be seriously broken: variables have not accessors, primitives have not senders... It seems that the primitives can be used without problems to access the locale properties of the host OS but it seems that itâs not possible to switch the locale. > On 08 Jan 2016, at 12:17, Trussardi Dario Romano <dario.trussardi(a)tiscali.it> wrote: > > Ciao, > > i work with Pharo4.0 Latest update: #40625 > > Now i need to setup the system to manage the Italy country > > - decimalSymbol ( , ) > - currencySymbol ( â¬ ) > > -dateFormat dd-MM-yyyy HH:mm > > How i can do it ? > > What is the Pharo system status about localization ? > > The: Locale current answer aLocale instance > > with id set to it-It > > but with all variables set to nil. > > > Thanks for any considerations, > > Dario

Jan. 8, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Henrik Johansen

> On 08 Jan 2016, at 3:24 , Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2016-01-08 15:17 GMT+01:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>>: > Which is why in terminate I do > myList := self suspend. > > So the semaphore *should* still be the suspendingList, just without the process actually on the list... > > I just test it in workspace. > sema := Semaphore new. > p := [sema wait] fork. > p suspend. > p suspendingList == nil > sema asArray isEmpty > Of course, that's something entirely different... if you do what I actually do in the modified terminate; sema := Semaphore new. p := [sema wait ] newProcess. p resume. 1 second wait. list := p suspend. "this list is (re)assigned to myList in terminate" list == nil list == sema You should get different answers. Cheers, Henry

Jan. 8, 2016

Re: [Pharo-dev] [Ann] ReadWriteLock

by Denis Kudriashov

2016-01-08 15:17 GMT+01:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: > Which is why in terminate I do > myList := self suspend. > > So the semaphore *should* still be the suspendingList, just without the > process actually on the list... > I just test it in workspace. sema := Semaphore new. p := [sema wait] fork. p suspend. p suspendingList == nil sema asArray isEmpty

Jan. 8, 2016

Re: [Pharo-dev] Changing performance balance between CPU & non-volatile storage

by Ben Coman

On Fri, Jan 8, 2016 at 9:17 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > On 07-01-16 20:07, Ben Coman wrote: >> >> An enlightening article (if a bit long). I wonder how non-volatile >> storage being faster than a CPU might affect Pharo systems. Perhaps >> the importance of migrating between live and backup Images gains in >> importance to backups via files. > > > I'm not sure what to think about it. I find it an rather vague and badly > written article. 100K iops is not close to saturating what a CPU core can > process. The problem is the communication and the article does a really good > job at confusing me about that. Further, commercial pricing is value based, > not cost. > > Stephan Yeah, I think I'll have to retract that about being enlightening, rather just a faÃ§ade of enlightenment. Many of the follow up comments on slashdot hit criticised it along the same lines and that its point of view is that of vendors selling fast-nvram. I probably shouldn't have posted it. Sorry for the noise. cheers -ben

Jan. 8, 2016