Re: [Pharo-dev] About being a real Pharo Jedi developer

> IMO, unloading is for the viewpoint of having an "ultimate image" > which is never replaced. Or, at least, not replaced from scratch while you're in the middle of day-to-day work and don't want to have to recreate a bunch of useful state somewhere else. Unloading has practical value. -C

Re: [Pharo-dev] Recovering _lost_ changes

That was my point. If we had a solid model of changes (and I expect epic to be like that), than I believe we could simply select the real changes since last save and apply them. Maybe some time :) Cheers. Uko > On 20 Nov 2015, at 23:11, Nicolai Hess wrote: > > > > 2015-11-20 23:01 GMT+01:

Re: [Pharo-dev] Recovering _lost_ changes

2015-11-20 23:01 GMT+01:00 Yuriy Tymchuk : > > > On 20 Nov 2015, at 17:52, Skip Lentz wrote: > > > > Hi, > > > >> On Nov 20, 2015, at 5:27 PM, Yuriy Tymchuk > wrote: > >> is Epicea integrated already? > > > > No, not yet I think. > > > >> If so, is it possible to apply all the changes to code (w

Re: [Pharo-dev] News about FastTable

Hi Cyril, more feedback about FTTree and #exampleTree1: - Moving the reject: before the sort: in ProtoObject allSubclasses cuts 40% of the time to run the example (-400ms) - Replacing all the asString by name divides that time by 9 (-900ms) Overall runtime went from > 1000ms to a bit above 1

Re: [Pharo-dev] Recovering _lost_ changes

> On 20 Nov 2015, at 17:52, Skip Lentz wrote: > > Hi, > >> On Nov 20, 2015, at 5:27 PM, Yuriy Tymchuk wrote: >> is Epicea integrated already? > > No, not yet I think. > >> If so, is it possible to apply all the changes to code (without doits) since >> the last image save? I think that it sh

Re: [Pharo-dev] Differences Compiler vs. OpalCompiler (or parser)

Hi Nicolai, On Fri, Nov 20, 2015 at 1:37 PM, Nicolai Hess wrote: > GTDummyExamples class > d: anInteger > > > anInteger'> > > MessageNotUnderstood> > > ^ 1 + anInteger > > The old Parser complains about the class name "MessageNotUnderstood" used > as a pragma > argum

[Pharo-dev] Differences Compiler vs. OpalCompiler (or parser)

GTDummyExamples class d: anInteger MessageNotUnderstood> ^ 1 + anInteger The old Parser complains about the class name "MessageNotUnderstood" used as a pragma argument without being a string or symbol Opal does not complain Is Opals behavior intended ? >From sque

[Pharo-dev] Unable to accept changes in SyntaxErrorDebugger -> DNU: receiver of asSymbol is nil

Any idea how to solve this: 16961 Unable to accept changes in SyntaxErrorDebugger -> DNU: receiver of asSymbol is nil and 16723

Re: [Pharo-dev] Opal problem causing crash but old compiler works [WAS] Re: [Vm-dev] Debugging VM crash, INVALID RECEIVER / a(n) bad class ??

2015-11-18 13:53 GMT+01:00 Mariano Martinez Peck : > Thanks Nicolai. Our monkey say it was success :) > Do you think Marcus should review it? or you confident enough? > > Now there is a bug tracker entry for pharo 4.0 too, and a fix, ready for testing. 17057

Re: [Pharo-dev] Kind of RBRenameMethodRefactoring but for closures?

Thierry, Sorry to bother again. Unfortunately, RB does not work out of the box in GemStone only the formatter part. grrr. Anyway, I am trying to make it work, and it's failing in this easy example: *| tree rewriter |* *tree := RBParser parseMethod: 'DoIt ^ [:proxy | proxy at: #oldSelector. ]

[Pharo-dev] [pharo-project/pharo-core]

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

[Pharo-dev] [pharo-project/pharo-core] 8c66dd: 50456

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 8c66dd7525db04dc03571f4aacca5bcb0a31c926 https://github.com/pharo-project/pharo-core/commit/8c66dd7525db04dc03571f4aacca5bcb0a31c926 Author: Jenkins Build Server Date: 2015-11-20 (Fri, 20 Nov 2015

Re: [Pharo-dev] Cleanup of debug requests API

Very nice. I remember when I made GTDebugger that there were way to many ways to open the debugger. I ended up just copy-pasting things. Would be very useful to have a small doc with what one needs to do to replace SpecDebugger with another debugger (e.g. what are the entry points of the debugger i

Re: [Pharo-dev] Cleanup of debug requests API

I clean and refactor all but lowSpaceWatcher. It is in slice 17069. In my image it is not broke stuff. So I hope it is safe change. 2015-11-20 12:18 GMT+01:00 Denis Kudriashov : > Hi > > I try to investigate how debugger opens and who initiates it. > I want to cleanup this logic and simplify curr

Re: [Pharo-dev] Does Pharo stores original author of methods?

2015-11-20 14:21 GMT+01:00 Marcus Denker : > epicea data is not stored forever. It is seasion based and the shipped > image is > clean. > But current source of this info is changes file (maybe sources). And I remember you planned to store current sources in image. And such information can be ther

Re: [Pharo-dev] Issue with large file path on windows

yes it was. latest win vm should have long paths. Esteban > On 20 Nov 2015, at 12:27, Blondeau Vincent > wrote: > > Hello, > > I would like to read from Pharo a file with a long name (so more than 255 > chars) under Windows. > A thread from last month (13 oct): “Re: [Pharo-dev] [Vm-dev] Re

[Pharo-dev] Issue with large file path on windows

Hello, I would like to read from Pharo a file with a long name (so more than 255 chars) under Windows. A thread from last month (13 oct): "Re: [Pharo-dev] [Vm-dev] Re: issue with large file path on windows", talks about a patch. Does it has been integrated? If it has, which VM should I take to h

Re: [Pharo-dev] Recovering _lost_ changes

Hi, > On Nov 20, 2015, at 5:52 PM, Skip Lentz wrote: > > For example, right now you will get an error when you redo (or undo) a class > comment change. I will try to fix this bug right now. I committed a bug fix for this to Epicea now.

Re: [Pharo-dev] Case 16725: why no reaction?

So now we stil have 2 subissues, that need discussion. They break backwards compatibility (basically it's about using Spec models instead of morphs in some methods). However it's not clear if these methods are widely used. So maybe transition will be painless, maybe not so much. We need to decid

Re: [Pharo-dev] Smalltalkhub is very instable this afternoon

Thx Esteban ! De : Pharo-dev [mailto:pharo-dev-boun...@lists.pharo.org] De la part de Esteban Lorenzano Envoyé : vendredi 20 novembre 2015 17:50 À : Pharo Development List Objet : Re: [Pharo-dev] Smalltalkhub is very instable this afternoon done On 20 Nov 2015, at 11:41, Blondeau Vincent mailt

Re: [Pharo-dev] Refactoring and traits…

Definitely had this (new methods are compiled in concrete classes instead of changing the trait method) several times, although I'm not sure if it was after refactoring, or something else (loading packages?). -- View this message in context: http://forum.world.st/Refactoring-and-traits-tp486222

Re: [Pharo-dev] Never ending BlockClosure>>benchFor:

So you can try the following... $ curl get.pharo.org/50+vm | bash $ ./pharo Pharo.image eval "Delay delaySchedulerClass: DelayExperimentalSemaphoreScheduler. CommandLineTestRunner runClasses: {GLMTreeMorphicTest. GLMWatcherMorphicTest. GLMPagerMorphTest} named: 'x'. CommandLineTestRunner runPac

Re: [Pharo-dev] Recovering _lost_ changes

Hi, > On Nov 20, 2015, at 5:27 PM, Yuriy Tymchuk wrote: > is Epicea integrated already? No, not yet I think. > If so, is it possible to apply all the changes to code (without doits) since > the last image save? I think that it should be really helpful because > searching for changes and cherr

Re: [Pharo-dev] Smalltalkhub is very instable this afternoon

done > On 20 Nov 2015, at 11:41, Blondeau Vincent > wrote: > > Hello, > > Can Smalltalkhub be restarted (or other) because it is impossible to work by > getting continuously errors 500, 503, 403, 401…. while loading or committing? > > TIA > > Cheers, > > Vincent BLONDEAU > > > Ce mes

Re: [Pharo-dev] About being a real Pharo Jedi developer

Good points. And, even if it all worked, would anyone still prefer not to simply rebuild an image with all the code? IOW, wouldn't they "trust" an image that was only built UP rather than one built up and then partially torn down? IMO, unloading is for the viewpoint of having an "ultimate image"

[Pharo-dev] Recovering _lost_ changes

Hi, is Epicea integrated already? If so, is it possible to apply all the changes to code (without doits) since the last image save? I think that it should be really helpful because searching for changes and cherry-picking them is a pain. Later this can be improved, so before the changes are ap

[Pharo-dev] SystemAnnouncer class>>#uniqueInstance

Hi, The class SystemAnnouncer has #restoreAllNotifications method that is called only by RPackageRenameTest>>setUp. This is pretty strange. I have an impression that tests should not affect global information (singleton). And there are some objects that depends on calling #restoreAllNotificatio

Re: [Pharo-dev] Never ending BlockClosure>>benchFor:

Could you try the various DelayExperimentalXXXSchedulers? Under System > Settings > System > Delay Scheduler. I believe there's a good chance one of them may fix also the problem. I had planned to push one of these as the default in Pharo 5 but hadn't decided which, got distracted and stretched a

Re: [Pharo-dev] Kernel-Tests and SystemAnnouncer

On Fri, Nov 20, 2015 at 12:44 PM, Peter Uhnák wrote: > And not just announcers, some of the tests there leave quite a footprint. > Indeed some tests are not designed to be silent. > I've recently discussed something similar with regards to performance > of subclassing in tests > > http://forum

[Pharo-dev] Smalltalkhub is very instable this afternoon

Hello, Can Smalltalkhub be restarted (or other) because it is impossible to work by getting continuously errors 500, 503, 403, 401 while loading or committing? TIA Cheers, Vincent BLONDEAU Ce message et les pi?ces jointes sont confidentiels et r?serv?s ?

Re: [Pharo-dev] Never ending BlockClosure>>benchFor:

On Fri, Nov 20, 2015 at 2:27 PM, Andrei Chis wrote: > Great catch! > > Can something similar be also the > reason SHTextStyler>>styleInBackgroundProcess: spawns zombie processes? > Even with this fix script [1] blocks in testBenchFor. If I apply the fix > proposed by ben in this thread or the sli

[Pharo-dev] Refactoring and traits…

Hi guys, is it a known issue that if you are refactoring something (eg. doing a class rename) and some changes should happen in a method which comes from trait, then new methods are compiled in concrete classes instead of changing the trait method? Cheers. Uko

Re: [Pharo-dev] Never ending BlockClosure>>benchFor:

Great catch! Can something similar be also the reason SHTextStyler>>styleInBackgroundProcess: spawns zombie processes? Even with this fix script [1] blocks in testBenchFor. If I apply the fix proposed by ben in this thread or the slice for issue 17050

Re: [Pharo-dev] Does Pharo stores original author of methods?

> On 20 Nov 2015, at 10:03, Denis Kudriashov wrote: > > Maybe we should include this information in new changes system (Epicea?) epicea data is not stored forever. It is seasion based and the shipped image is clean. This information needs to be in the repository. That is why one has a reposit

Re: [Pharo-dev] Does Pharo stores original author of methods?

or just use git *run and hides* On Fri, Nov 20, 2015 at 3:04 PM Denis Kudriashov wrote: > Maybe we should include this information in new changes system (Epicea?) > > 2015-11-20 13:50 GMT+01:00 Marcus Denker : > >> >> > On 20 Nov 2015, at 09:46, Denis Kudriashov >> wrote: >> > >> > Hi. >> > >>

Re: [Pharo-dev] Never ending BlockClosure>>benchFor:

On Fri, Nov 20, 2015 at 2:00 PM, Thierry Goubier wrote: > > > 2015-11-20 13:44 GMT+01:00 Sven Van Caekenberghe : > >> >> > On 20 Nov 2015, at 13:03, Thierry Goubier >> wrote: >> > >> > >> > >> > 2015-11-20 12:46 GMT+01:00 Martin Dias : >> > Hi! >> > >> > With Guille and Pablo this morning we fou

Re: [Pharo-dev] Never ending BlockClosure>>benchFor:

https://pharo.fogbugz.com/f/cases/17066/Problem-scheduling-delay-from-a-low-priority-process On Fri, Nov 20, 2015 at 12:46 PM, Martin Dias wrote: > Hi! > > With Guille and Pablo this morning we found what is the problem and > apparently fixed it. The problem is that there is a process in priorit

Re: [Pharo-dev] Does Pharo stores original author of methods?

Maybe we should include this information in new changes system (Epicea?) 2015-11-20 13:50 GMT+01:00 Marcus Denker : > > > On 20 Nov 2015, at 09:46, Denis Kudriashov wrote: > > > > Hi. > > > > Is information about original authors of methods exists in sources of > image? > No. > > > I found only

Re: [Pharo-dev] Never ending BlockClosure>>benchFor:

2015-11-20 13:44 GMT+01:00 Sven Van Caekenberghe : > > > On 20 Nov 2015, at 13:03, Thierry Goubier > wrote: > > > > > > > > 2015-11-20 12:46 GMT+01:00 Martin Dias : > > Hi! > > > > With Guille and Pablo this morning we found what is the problem and > apparently fixed it. The problem is that there

Re: [Pharo-dev] Does Pharo stores original author of methods?

> On 20 Nov 2015, at 09:46, Denis Kudriashov wrote: > > Hi. > > Is information about original authors of methods exists in sources of image? No. > I found only authors of last methods modification. Nautilus combobox > source/timestamp. > > It will be useful to know who introduce some particu

[Pharo-dev] Does Pharo stores original author of methods?

Hi. Is information about original authors of methods exists in sources of image? I found only authors of last methods modification. Nautilus combobox source/timestamp. It will be useful to know who introduce some particular method to ask him questions directly. Now when we doing refactoring many

[Pharo-dev] [pharo-project/pharo-core]

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

Re: [Pharo-dev] Never ending BlockClosure>>benchFor:

> On 20 Nov 2015, at 13:03, Thierry Goubier wrote: > > > > 2015-11-20 12:46 GMT+01:00 Martin Dias : > Hi! > > With Guille and Pablo this morning we found what is the problem and > apparently fixed it. The problem is that there is a process in priority 10 > that takes the delay lock (accessP

[Pharo-dev] [pharo-project/pharo-core] 8232e5: 50455

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 8232e53d28e2f093d85a061890fca43f1178f0a3 https://github.com/pharo-project/pharo-core/commit/8232e53d28e2f093d85a061890fca43f1178f0a3 Author: Jenkins Build Server Date: 2015-11-20 (Fri, 20 Nov 2015

Re: [Pharo-dev] Never ending BlockClosure>>benchFor:

2015-11-20 12:46 GMT+01:00 Martin Dias : > Hi! > > With Guille and Pablo this morning we found what is the problem and > apparently fixed it. The problem is that there is a process in priority 10 > that takes the delay lock (accessProtect semaphore) and go to sleep. Then > the #benchFor: launches

Re: [Pharo-dev] Never ending BlockClosure>>benchFor:

Hi! With Guille and Pablo this morning we found what is the problem and apparently fixed it. The problem is that there is a process in priority 10 that takes the delay lock (accessProtect semaphore) and go to sleep. Then the #benchFor: launches another process in priority 79 that tries to take the

Re: [Pharo-dev] Kernel-Tests and SystemAnnouncer

And not just announcers, some of the tests there leave quite a footprint. I've recently discussed something similar with regards to performance of subclassing in tests http://forum.world.st/fast-subclassing-class-creation-in-tests-td4857779.html So Kernel-Tests might also benefit from it. Right n

[Pharo-dev] Kernel-Tests and SystemAnnouncer

Hi, Ideally shouldn't Kernel-Tests, or tests in general, be silent and not trigger a lot of system announcers? Right now Kernel-Tests trigger around 250 announcements through the SystemAnnouncer. Cheers, Andrei

Re: [Pharo-dev] ConfigurationOfIDE working again

Le 19/11/15 22:45, Pavel Krivanek a écrit : Hi Stef, 2015-11-19 21:44 GMT+01:00 stepharo >: Pavel may be you want to sync with christophe because he is working hard on getting the bootstrap working for real :) I already talked to him about a month ago

[Pharo-dev] Cleanup of debug requests API

Hi I try to investigate how debugger opens and who initiates it. I want to cleanup this logic and simplify current debugger API. I found that basic error debugging starts with UIManager then UIManager calls SpecDebugger, then SpecDebugger calls UIManager and again... At the end of this chain debu

Re: [Pharo-dev] About being a real Pharo Jedi developer

Thanks for the info. I think i am on safe side of things since I dont mess with pharo internals. You say if I override an existing method, that method cannot be recovered, but that is strange since the system does have versions for each method , so I assume here that is not that is not possible ra

Re: [Pharo-dev] About being a real Pharo Jedi developer

Stef writes: > When I was getting to be a Jedi, my Yoda master (Joseph Pelrine) told > me the following (yes back in 96) > > translated from Yoda language: > > you will be a real Jedi when your code will load in one click! > you will be a real Jedi when your code will unload in one c

Re: [Pharo-dev] opal optimize to do limits

Hi Nicolai, > On Nov 20, 2015, at 12:33 AM, Nicolai Hess wrote: > > Thanks eliot, Clement, > > but if the argument for to:do: is not an expression but one of the method > argument, this > transformation is not needed. Or still? That's the corollary to what I said. Since method (*) arguments

Re: [Pharo-dev] EyeInspector with subclasses of ProtoObject

Hi Guille, > On Nov 19, 2015, at 9:11 AM, Guillermo Polito > wrote: > > >> On 19 nov 2015, at 5:46 p.m., Clément Bera wrote: >> >> >> >> 2015-11-19 10:33 GMT+01:00 Guillermo Polito : >>> I know we can :) and I did some prototypes already as part of my thesis. >>> >>> The question is if th

Re: [Pharo-dev] opal optimize to do limits

Thanks eliot, Clement, but if the argument for to:do: is not an expression but one of the method argument, this transformation is not needed. Or still? 2015-11-20 8:31 GMT+01:00 Clément Bera : > You can use whileTrue: if it's a problem for you not to evaluate the limit > at each iteration of

Re: [Pharo-dev] About being a real Pharo Jedi developer

Le 19/11/15 23:13, Chris Muller a écrit : translated from Yoda language: you will be a real Jedi when your code will load in one click! In Yoda grammar: "When, in one click, your code will load, then, and only then, a Jedi will you be..." :) Thanks my decoder was not working well :)