- Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

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

June 29, 2014

Re: [Pharo-dev] ctrl+a is seen as ctrl+home windows

by Denis Kudriashov

Hi hasSpecialCTRLKeyValue was extracted by me when I hack keybindings to make ctrl+home and ctrl+end working. Like you I was very surprised by such keyboard events crappy state. 2014-06-25 11:22 GMT+04:00 Nicolai Hess <nicolaihess(a)web.de>: > 2014-06-25 8:58 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > > There is a problem in the whole keyboard events: they treat keys as >> characters and vice versa. And that's not always true: >> - the backspace key is a key, but currently the image interprets it as a >> character because we only use keypress events in general. >> - the shift key is a key, and since current image does not use keyup nor >> keydown, we cannot know if JUST a shift is pressed normally. >> >> >> On Wed, Jun 25, 2014 at 8:53 AM, Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >> >>> I don't know anything about event handling, but I once had a look at >>> Character constants, and found this: >>> >>> Character class>>#home >>> ^ self value: 1 >>> >>> How about that ?? This is wrong IMHO, ASCII / Unicode value 1 is SOH >>> (Start of header), sometimes typed as CTRL-A. And there are other strange >>> constants like that there. >>> >>> On 25 Jun 2014, at 08:42, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>> > Hi, >>> > >>> > I am on Windows, using Pharo 3.0, and I am trying to get the >>> keybindings to work in Rubric using Windows convention (so, Ctrl instead of >>> Cmd as a modifier), >>> > >>> > It worked reasonably well, but the problem is that somehow Ctrl+a is >>> mapped to Ctrl+Home. The problem is not specific to Rubric as I can detect >>> the same behavior in the regular PluggableTextMorph. >>> > >>> > Does anyone have an idea of where the problem comes from? >>> > >>> > Doru >>> > >>> > >>> > >>> > -- >>> > www.tudorgirba.com >>> > >>> > "Every thing has its own flow" >>> >>> >>> >> > > ctrl+a has the same strange behavior as ctrl+d > ctrl+a -> ctrl+home > ctrl+d -> ctrl+end > > look at KeyboardEvent>>#hasSpecialCTRLKeyValue > I am not exactly sure why it is handled that way. > Replace the method with > > hasSpecialCTRLKeyValue > ^ self controlKeyPressed and: [ keyValue <= 26 ] > > now, ctr+a and ctr+d working as expected. > But I don't know about the side-effects. > > > nicolai > >

June 29, 2014

Re: [Pharo-dev] https://pharo.fogbugz.com/default.asp?13422

by Johan Brichau

On 29 Jun 2014, at 15:24, GOUBIER Thierry <thierry.goubier(a)cea.fr> wrote: > What i'd be worried with is the high number of PackageTreePackageNodeModel->102250. Each node model suppose a NodeMorph, and so on... And, stef, I don't think your test was loading one hundred thousand packages, isn't it? It was me ;-) (fogbugz sends email as Stef?) Exactly, this is where I am looking at. I have tried to find who is referencing all those instances but I have not discovered it yet. > I'd look into the package tree structure and updates. I started to look at the single PackageTreeNautilusUI instance I have open which should be the root that is keeping all these instance in the image. But I am wandering through unknown code here... Johan

June 29, 2014

Re: [Pharo-dev] about ~=

by Ben Coman

June 29, 2014

Re: [Pharo-dev] https://pharo.fogbugz.com/default.asp?13422

by Ben Coman

GOUBIER Thierry wrote: > What i'd be worried with is the high number of PackageTreePackageNodeModel->102250. Each node model suppose a NodeMorph, and so on... And, stef, I don't think your test was loading one hundred thousand packages, isn't it? > > I'd look into the package tree structure and updates. > > Thierry > In the past to investigate similar stuff I've used a bad hack like this... 1. In Workspace evaluate: Smalltalk at: #senders put: Bag new. 2. Define method... PackageTreePackageNodeModel class>>new | senderString | senderString := thisContext sender printString , '<--' , thisContext sender sender printString , '<--' , thisContext sender sender sender printString . "to whatever depth is useful" (Smalltalk at: #senders) add: senderString. ^ super new. I've also output the senderStrings to a log file and loaded into Excel to munge things for pattern matching. Very agricultural approach, but it turned up some results (though I can't remember what it was for.) However I've never actually plugged that sort of thing into #new, so YMMV. Also note that if you happen to step through the above code with the debugger, thisContext might not be set properly [1], although it works fine outside the debugger. [1] https://pharo.fogbugz.com/f/cases/12980/ cheers -ben > ________________________________________ > De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de stepharo [stepharo(a)free.fr] > EnvoyÃ© : dimanche 29 juin 2014 10:38 > Ã : Pharo Development List > Objet : [Pharo-dev] https://pharo.fogbugz.com/default.asp?13422 > > I did an 'Smalltalk allClasses collect:[:cl | cl -> cl allInstances > size]' before starting a load and right after a load that just does not > crash the image. I noticed the following number of new instances that > were still being referenced (i.e. not garbage collected). > > The following lists the number of _added_ instances during the load with > the largest first. I include all of them but some are obviously more > indicative than others. > > Float->3580540 > Point->2149989 > Rectangle->818991 > Array->573089 > MorphExtension->309932 > TableLayoutProperties->204571 > ByteString->108891 > OrderedCollection->107527 > IdentityDictionary->103768 > ImageMorph->102338 > StringMorph->102318 > Morph->102313 > DependentsArray->102309 > TableLayout->102308 > RowLayout->102259 > MorphTreeNodeMorph->102252 > PackageTreePackageNodeModel->102250 > Association->26405 > Duration->14081 > CompiledMethod->11191 > MethodChangeRecord->11131 > IdentitySet->10843 > .... > > > >

June 29, 2014

Re: [Pharo-dev] https://pharo.fogbugz.com/default.asp?13422

by GOUBIER Thierry

What i'd be worried with is the high number of PackageTreePackageNodeModel->102250. Each node model suppose a NodeMorph, and so on... And, stef, I don't think your test was loading one hundred thousand packages, isn't it? I'd look into the package tree structure and updates. Thierry ________________________________________ De : Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de stepharo [stepharo(a)free.fr] EnvoyÃ© : dimanche 29 juin 2014 10:38 Ã : Pharo Development List Objet : [Pharo-dev] https://pharo.fogbugz.com/default.asp?13422 I did an 'Smalltalk allClasses collect:[:cl | cl -> cl allInstances size]' before starting a load and right after a load that just does not crash the image. I noticed the following number of new instances that were still being referenced (i.e. not garbage collected). The following lists the number of _added_ instances during the load with the largest first. I include all of them but some are obviously more indicative than others. Float->3580540 Point->2149989 Rectangle->818991 Array->573089 MorphExtension->309932 TableLayoutProperties->204571 ByteString->108891 OrderedCollection->107527 IdentityDictionary->103768 ImageMorph->102338 StringMorph->102318 Morph->102313 DependentsArray->102309 TableLayout->102308 RowLayout->102259 MorphTreeNodeMorph->102252 PackageTreePackageNodeModel->102250 Association->26405 Duration->14081 CompiledMethod->11191 MethodChangeRecord->11131 IdentitySet->10843 ....

June 29, 2014

Re: [Pharo-dev] Pharo and Amber relationship

by Sebastian Sastre

check this out: http://runtimejs.org sebastian o/ > On 26/06/2014, at 13:44, stepharo <stepharo(a)free.fr> wrote: > > Running Pharo on JS VM would be interesting too. > > Stef

June 29, 2014

Re: [Pharo-dev] New Cog VMs available

by stepharo

thanks eliot. Esteban is on his way back to France and we will sync with him probably tuesday. Stef On 29/6/14 06:02, Eliot Miranda wrote: > ...in http://www.mirandabanda.org/files/Cog/VM/VM.r3021/. > > In particular, these fix VM crashes when running the AllocationTest in > Spur. > > CogVM source as per VMMaker.oscog-eem.787/r3021 > > Fix mixup of old & young spaces in primitiveVMParameter, and > comment some new parameters. > > Fix return types for positive[64/32]BitValueOf:. > positive32BitValueOf: must answer a usqInt, > positive64BitValueOf: must answer a usqLong. > > Use positiveMachineIntegerValueOf: to decode arg in primitiveNewWithArg > and ensure positiveMachineIntegerValueOf: is inlined there-in. > > win32: > Set the IMAGE_FILE_LARGE_ADDRESS_AWARE flag in the image header of the > Windows > executables to allow e.g. Spur to allocate more than 2Gb. > > Spur: > Fix sign and overflow issues in instantiating larger objects > and determining the size of large instances. > > Fix some freeChunk accesses that used fetchPointer:ofObject:. > > Cog ARM: > Fix prim return for compileInterpreterPrimitive: on RISCs. On return from > interpreter prim, ret pc is in instructionPointer and must return to > whence > it came, which is the stack on CISC and the LinkReg on RISC. Hence > restoring > the receiver reg requires different offsets in the two cases. > > Rework the rotatable quick constant logic a little and clean up users. > Fix concretizeMoveRXbrR to do byte not word loads. > Fix concretizeConditionalJumpLong: to actually be conditional. Oops. > > Correct mistaken callersaved reg stuff for ARM > Fix concretizedRetN to not over-bump the SP > > The method abort trampolines shouldn't pop anything, especially > now we have the pushLinkreg: arg to manage the LinkReg more easily. > > Slang: > Rip out the UseRightShiftForDivide optimization. It gets unsigned > division > wrong, and C compilers can and will optimize this correctly themselves. > > > -- > best, > Eliot

June 29, 2014

Re: [Pharo-dev] http://files.pharo.org/platform/Pharo3.0-win.zip looks like dead

by Tudor Girba

Works for me. Doru On Sun, Jun 29, 2014 at 10:49 AM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Not downloading.... > > Annoying, I wanted to demo Pharo to someone from scratch :-( > > Phil > -- www.tudorgirba.com "Every thing has its own flow"

June 29, 2014

Re: [Pharo-dev] TaskIT Revealed

by Tudor Girba

And the script:) Gofer new smalltalkhubUser: 'CAR' project: 'TaskIT'; configuration; load. (#ConfigurationOfTaskIT asClass project version: #stable) load: 'full' Cheers, Doru On Sun, Jun 29, 2014 at 11:09 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Thanks! > > This works. > > For reference, here is the loading script: > > > Cheers, > Doru > > > > > On Sun, Jun 29, 2014 at 9:58 AM, Santiago Bragagnolo < > santiagobragagnolo(a)gmail.com> wrote: > >> Hi Doru! >> >> Download the stable version ConfigurationOfTaskIt stable. >> >> We are going through a refactor that adds new concepts, the last code is >> very unstable. We will try to make them transparent from the API point of >> view, but it will add new concepts in all the aspects. >> >> >> >> >> >> 2014-06-29 7:48 GMT+02:00 Tudor Girba <tudor(a)tudorgirba.com>: >> >> Hi, >>> >>> This sounds very nice! >>> >>> I am trying to give it a shot, but I encounter a DNU for >>> BlockClosure>>asTask. I have loaded the latest code from all packages, but >>> this method is not defined. >>> >>> Cheers, >>> Doru >>> >>> >>> On Mon, Jun 23, 2014 at 7:32 AM, Santiago Bragagnolo < >>> santiagobragagnolo(a)gmail.com> wrote: >>> >>>> In general terms there are pharo processes. >>>> >>>> val := [2+2] shooitIt. >>>> >>>> val := [2+2] scheduleIt. >>>> >>>> val := [2+2] forkIt. >>>> >>>> >>>> >>>> All of this snippets will give you a future, all will be related with a >>>> pharo process, but each process has different meaning. the firstone is a >>>> common 2+2 block opened in a pharo process. the second one is a block >>>> assigned to one of the by-default two worker pharo processes from the >>>> thread pool. ( in this case the pharo processes do not run directly the >>>> task, but run a process that run tasks. Then, the first one is applied just >>>> there, the second one when is its turn. >>>> >>>> Finally the third one will use osprocess to open the same image (so, by >>>> now, this will work without anyproblem if you have saved the image just >>>> before, or if you didnt change any of the code to be executed) with the >>>> same vm and it will give the block to be executed. In our local image, >>>> there will be spawned a watch pharo process that will check if the third >>>> image has finished, and deploy the future for it. >>>> >>>> >>>> In the behind the scenes, each of this convenient methods is >>>> implemented with a different kind of runner and process reification. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> 2014-06-23 0:54 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: >>>> >>>> are those OS processes or Pharo processes ? >>>>> >>>>> >>>>> On Mon, Jun 23, 2014 at 1:39 AM, Santiago Bragagnolo < >>>>> santiagobragagnolo(a)gmail.com> wrote: >>>>> >>>>>> >>>>>> Hi all, im glad to announce TaskIT. You may already knew about, after >>>>>> all it's not confidential ;) and it has documentation on-going since some >>>>>> months ago. >>>>>> >>>>>> Task IT is package that provides a cool way to deal with processes. >>>>>> Even when this version is stable, it still in design and we want to make it >>>>>> consistent and powerfull. >>>>>> >>>>>> It counts with a chapter in pharo enterprise book and some cool >>>>>> tests. >>>>>> >>>>>> We have moved the main distribution repo to CAR >>>>>> >>>>>> http://smalltalkhub.com/#!/~CAR/TaskIT/ >>>>>> >>>>>> >>>>>> The main easy things to do with this revision are: >>>>>> >>>>>> " closures " >>>>>> val := [ 2+2 ] shootIt. >>>>>> val isKindOf: TKTFuture. >>>>>> val onSuccess: [: rslt | rslt == 4 ] "async" >>>>>> val value == 4. " sync " >>>>>> >>>>>> rslt := [ 2+2 ] shootIt asResult. >>>>>> rslt == 4 "sync on demand" >>>>>> >>>>>> " objects " >>>>>> >>>>>> val := 2 paralellize + 2. >>>>>> val == 4 "sync on demand" >>>>>> >>>>>> >>>>>> " staying in tune " >>>>>> >>>>>> val := [ "some task" ] shootIt asStickyReference. >>>>>> >>>>>> val := nil. >>>>>> " sticky means that if this future is taken by the GC, it will kill >>>>>> the process" >>>>>> >>>>>> >>>>>> >>>>>> " looping " >>>>>> >>>>>> >>>>>> val := server paralellize looping serveOnce: anyParameter >>>>>> asStickyReference. >>>>>> >>>>>> "this will execute in a new process, in a loop, server serveOnce: >>>>>> anyParameter." >>>>>> >>>>>> You can stop it by doing >>>>>> val:= nil. >>>>>> >>>>>> "or using a disgusting magic variable, for that check the samples :). >>>>>> But do not rely on that kind of things, because it will not be supported " >>>>>> >>>>>> >>>>>> >>>>>> For more advanced and cool usages, check the Doc. >>>>>> >>>>>> >>>>>> FAQ: >>>>>> >>>>>> 1- Yes, the "sync" on demand is implemented with a proxy and a >>>>>> become. >>>>>> 2- Yes, we are changing the API of the processes that persist in >>>>>> time. >>>>>> >>>>>> CREDITS >>>>>> All CAR team in general was great inspiration, particularly, Guille >>>>>> Polito full operational commiter and of course is always a good idea to >>>>>> discuss with him, Nick Papoylias, is also great to discuss with him. Luc, >>>>>> Noury, Jannik: several ideas are discussed with them as well, and they >>>>>> always gave me support. >>>>>> >>>>>> and from RMOD Esteban Lorenzano, also discussing and proposing. >>>>>> >>>>>> Thanks all :). >>>>>> >>>>>> >>>>>> OTHERS: >>>>>> If you want to go to the darkside (dark because is not documented >>>>>> yet, but in the case of PoolIT, that it has some doc ) you can also add to >>>>>> your combo: >>>>>> ActIT: a simple Actor extention for taskit. >>>>>> ForkIT: an extention that runs blocks in background image (it adds a >>>>>> nice button to the test runner, letting you run all your tests in a >>>>>> background image and installing the results after the execution) >>>>>> PoolIT: it adds a pool of workers, it consumes tasks and ensure you a >>>>>> limited amount of threads. >>>>>> PlanIT: a basic and not yet full developed algebra for composing >>>>>> processes. >>>>>> >>>>>> >>>>>> >>>>>> I encourage you to use it, it is being used in PhaROS since a lot of >>>>>> time. And please any bug and enhancements, you can contact us. Since we are >>>>>> working on the next version is a good time to define what features are >>>>>> really needed. >>>>>> >>>>>> >>>>>> Salut. >>>>>> >>>>>> >>>>>> Santiago. . >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing has its own flow" >>> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- www.tudorgirba.com "Every thing has its own flow"

June 29, 2014