- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Moose-dev] Re: gtdebugger in pharo 5.0
by Sven Van Caekenberghe Jan. 10, 2016

Jan. 10, 2016

> On 10 Jan 2016, at 21:14, Ferlicot D. Cyril <cyril.ferlicot(a)gmail.com> wrote: > > Le 08/01/2016 12:07, Tudor Girba a Ã©crit : >> 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: >> >> >> >> 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/ >> >> 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?" >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> > > Hi, > > An other thing that came in my mind is that, for now, GTDebugger lack > documentation. > Some classes have no documentation and the class with a comment only > have 1 line and don't follow the template. > > It's good that people takes time to add documentation but if the new > classes that Pharo include does not have a proper documentation (class > doc + comments in complex methods) we will never be able to have a > version of Pharo with a good documentation. > > I think that we should not integrate new classes if they don't have a > class comment that follow the template. +100 I can understand that when prototype, hacking, being generally productive inside Pharo, you don't write comments at first. But once you go public, after some iterations, and especially if you want to be integrated into Pharo itself, there is no excuse. We need proper class comments, and comments for the main non-trivial public methods. Sven > -- > Cyril Ferlicot > > http://www.synectique.eu > > 165 Avenue Bretagne > Lille 59000 France > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev

3 3

[pharo-project/pharo-core]
by GitHub Jan. 10, 2016

Jan. 10, 2016

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

1 0

Just that you know that we are not happy
by stepharo Jan. 10, 2016

Jan. 10, 2016

Hi if GTdebugger becomes the default debugger it means that our mooc will be already obsolete before getting finished. It means that we will be forced to have separate installers different web pages explaining not to use Pharo 50 but a strange version it means that people will report bugs on a different system And we will have to spent time on that instead of the rest. And we will really thank the Pharo community for its great vision and care about our effort. This is more than 6 months that we are working on it and we have problably yet another month of work. Now just writing this makes me sick. So if the only respect about the work of other people is like that then I will just think a lot about my engagement. If this happens I can tell you that you will have a hard time to ask me to put energy into pharo in the future. Now if this makes you feel easy you can think that I'm tired. This poor stephane is working too much and is overacting. Think that if this helps you to feel good. Really. Now what pissed me off the most is that I'm **TEACHING** to L2 L3 and M1 students This year I was teaching to Prague Annecy Lviv Lome Dakar Saint louis Yaounde and when I say that the student are afraid by the default debugger, they are afraid also by a more complex one. Who among the people deciding to not put this debugger by default can show me that he did one lecture on newbies over the last two years? For real? So be right and go ahead: because you know what is good for the end programmer. I asked five times to understand who need _thisContext and _stakc top and so far I got zero answer. It will help me to take a break from Pharo. Stef PS: I 'm not in the Pharo board anymore because I have to do something else

4 8

[pharo-project/pharo-core]
by GitHub Jan. 10, 2016

Jan. 10, 2016

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

1 0

Differentiate ProcessList and LinkedList - incomplete
by Ben Coman Jan. 10, 2016

Jan. 10, 2016

LinkedList is a generic concept but historically has been intimately coupled to Process scheduling. While trying to make LinkedList API more generic, Pharo inadvertently introduced some problems with Processes, so we decided to copy LinkedList to ProcessList so this can remain specialised for Process scheduling, allowing LinkedList the opportunity to be more generic. Here is some history at fogbugz.pharo.com: Background... Case 5602 "LinkedList at: index putLink: aLink" Case 10273 "Cleaning Linked List API" Changes... Case 15868 "Differentiate ProcessList and LinkedList" Case 15871 "enable ProcessList" Case 17277 "newSpecialObjectsArray should return a process list instead of a linked list at item 41" Semaphore rather intimately manipulates the process list, but it seems to have been missed as it still inherits from LinkedList. Should it subclass ProcessList instead? I guess FreeTypeCacheLinkedList and Stack can remain where they are. So also a question for the Squeak, Cuis & Newspeak communities... There are various references to LinkedList in the VM [1]. Currently only in comments but there are hints down the track there could be more direct use. So I am wondering how these groups would feel about aligning with Pharo on this change, so the comments in the VM can be updated accordingly? cheers -ben [1] https://git.io/vuQQk

2 1

Re: [Pharo-dev] [squeak-dev] valid pragma syntax
by Nicolai Hess Jan. 10, 2016

Jan. 10, 2016

2016-01-10 13:14 GMT+01:00 Levente Uzonyi <leves(a)caesar.elte.hu>: > > On Sun, 10 Jan 2016, Nicolai Hess wrote: > > pharo fogbugz issue: 17359 MessageNotUnderstood: receiver of "keywords" is >> nil >> >> >> is this valid pragma syntax: >> >> <apicall: bool 'SetCursorPos' (long long) module: 'user32.dll'> >> > > This is not a pragma, but the special syntax used by FFI. AFAIK it > predates pragmas. > Ah, ok. > > >> our (pharo) parser can not parse this (does not recognizes the >> "selector parts" (apicall:module:) right) >> >> Any recommendations how to fix this >> - fix RBParser or >> - change this pragma, for example, like this >> <apicall: #(bool SetCursorPos (long long)) module: 'user32.dll'> >> > > There's nothing to fix here. Either you change your parser, compiler and > decompiler to support this syntax, but knowing how things work in Pharo, > this is not an option Why is this not an option? > , or change the methods with these callouts, introducing another > incompatibility between Pharo and the rest, to use pragmas and create a > custom parser, compiler and decompiler to be able to compile FFI callouts > into methods when such pragmas are present. > As we now included this FFI-Examples, where this is used, I would like to find a way that works in both, pharo and squeak. @esteban is this already supported by "our" FFI and just not by the parser used for syntax highlighting or wasn't this package supposed to be in Pharo ? > > Levente > > >> >> nicolai >> >> > > >

1 0

Little challenge
by stepharo Jan. 10, 2016

Jan. 10, 2016

We are trying to find examples of variableSubclass:... and with source code we could not find them. Even looking in all the code did not work. finally Object allSubclasses select: #isVariable worked but it would be good that search to the code would take into account classdefinitions. Or may be it does. Stef and Luc working on the Pharo Mooc

2 3

Help with FFI crash in latest Spur (only in Linux)
by Mariano Martinez Peck Jan. 9, 2016

Jan. 9, 2016

Hi guys, I wonder if someone could give me a hand to find out why a FFI calling I am doing is crashing. In OSX it works correct but I am testing in CentOS and it fails. I wonder if it also crashes in other Linuxes too. I am using latest Pharo 5.0 with Spur. To reproduce: 1) Get latest Pharo 5.0 and Spur via: wget -O- get.pharo.org/alpha+vm | bash 2) Inside Pharo, load my prototype tool: Gofer it package: 'OSSubprocess'; url: 'http://smalltalkhub.com/mc/marianopeck/OSSubprocess/main'; load. 3) This is the code I am executing and it's crashing: | posixSpawnFileActionsT | posixSpawnFileActionsT := ExternalAddress allocate: 4. OSSUnixSubprocess new primitivePosixSpawnFileActionsInit: posixSpawnFileActionsT. posixSpawnFileActionsT free. 4) The primitive is as simple as: primitivePosixSpawnFileActionsInit: aPosixSpawnFileActionsT ^ self ffiCall: #( int posix_spawn_file_actions_init(void* aPosixSpawnFileActionsT) ) module: LibC I have no idea what I am doing wrong. And again, this works on OSX. The function I am calling is: int posix_spawn_file_actions_init(posix_spawn_file_actions_t *file_actions); as you can read in [1] Below is the stacktrace I get the Linux terminal. Any hint is greatly appreciated. Thanks, [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_spawn_file_… **** Error in `/home/centos/pharo-vm/pharo': malloc(): memory corruption (fast): 0x09544268 **** ======= Backtrace: ========= /lib/libc.so.6(+0x7428c)[0xf758e28c] /lib/libc.so.6(+0x76d98)[0xf7590d98] /lib/libc.so.6(__libc_calloc+0xa7)[0xf7592df7] /home/centos/pharo-vm/pharo[0x80b8f44] /home/centos/pharo-vm/pharo[0x80b909c] /home/centos/pharo-vm/pharo(ioLoadExternalFunctionOfLengthFromModuleOfLengthAccessorDepthInto+0xc2)[0x80b9402] /home/centos/pharo-vm/pharo[0x808de6f] /home/centos/pharo-vm/pharo[0x80a0810] /home/centos/pharo-vm/pharo(ceSendsupertonumArgs+0x1da)[0x80a1f4a] [0x960004c] [0x9600b00] [0xaec2e9b] [0xaec3481] [0x9604ff0] [0x964ed43] [0x9604f5c] [0x960424c] [0x9602e47] [0x9602be7] [0x960320c] [0x9602277] [0x960bec2] [0x9600b00] [0x9600ad8] ======= Memory map: ======== 08048000-08151000 r-xp 00000000 fd:01 202178584 /home/centos/pharo-vm/pharo 08151000-08152000 r--p 00108000 fd:01 202178584 /home/centos/pharo-vm/pharo 08152000-0815c000 rw-p 00109000 fd:01 202178584 /home/centos/pharo-vm/pharo 0815c000-08193000 rw-p 00000000 00:00 0 09505000-095a5000 rw-p 00000000 00:00 0 [heap] 09600000-09701000 rwxp 00000000 00:00 0 09701000-0dbc0000 rw-p 00000000 00:00 0 f6de5000-f6dfe000 r-xp 00000000 fd:01 203854803 /usr/lib/libgcc_s-4.8.5-20150702.so.1 f6dfe000-f6dff000 r--p 00018000 fd:01 203854803 /usr/lib/libgcc_s-4.8.5-20150702.so.1 f6dff000-f6e00000 rw-p 00019000 fd:01 203854803 /usr/lib/libgcc_s-4.8.5-20150702.so.1 f6e00000-f6e21000 rw-p 00000000 00:00 0 f6e21000-f6f00000 ---p 00000000 00:00 0 f6f25000-f6f26000 rw-p 00000000 00:00 0 f6f26000-f6f2e000 r-xp 00000000 fd:01 202178580 /home/centos/pharo-vm/libSqueakFFIPrims.so f6f2e000-f6f2f000 r--p 00007000 fd:01 202178580 /home/centos/pharo-vm/libSqueakFFIPrims.so f6f2f000-f6f30000 rw-p 00008000 fd:01 202178580 /home/centos/pharo-vm/libSqueakFFIPrims.so f6f30000-f6f32000 r-xp 00000000 fd:01 203140415 /usr/lib/libXau.so.6.0.0 f6f32000-f6f33000 r--p 00001000 fd:01 203140415 /usr/lib/libXau.so.6.0.0 f6f33000-f6f34000 rw-p 00002000 fd:01 203140415 /usr/lib/libXau.so.6.0.0 f6f34000-f6f5b000 r-xp 00000000 fd:01 201498737 /usr/lib/liblzma.so.5.0.99 f6f5b000-f6f5d000 r--p 00026000 fd:01 201498737 /usr/lib/liblzma.so.5.0.99 f6f5d000-f6f5e000 rw-p 00028000 fd:01 201498737 /usr/lib/liblzma.so.5.0.99 f6f5e000-f6fc0000 r-xp 00000000 fd:01 201348055 /usr/lib/libpcre.so.1.2.0 f6fc0000-f6fc2000 r--p 00061000 fd:01 201348055 /usr/lib/libpcre.so.1.2.0 f6fc2000-f6fc3000 rw-p 00063000 fd:01 201348055 /usr/lib/libpcre.so.1.2.0 f6fc3000-f6fcf000 r-xp 00000000 fd:01 202740809 /usr/lib/libdrm.so.2.4.0 f6fcf000-f6fd0000 r--p 0000b000 fd:01 202740809 /usr/lib/libdrm.so.2.4.0 f6fd0000-f6fd1000 rw-p 0000c000 fd:01 202740809 /usr/lib/libdrm.so.2.4.0 f6fd1000-f6fd5000 r-xp 00000000 fd:01 202740799 /usr/lib/libXxf86vm.so.1.0.0 f6fd5000-f6fd6000 r--p 00004000 fd:01 202740799 /usr/lib/libXxf86vm.so.1.0.0 f6fd6000-f6fd7000 rw-p 00005000 fd:01 202740799 /usr/lib/libXxf86vm.so.1.0.0 f6fd7000-f6fd8000 r-xp 00000000 fd:01 201522922 /usr/lib/libxshmfence.so.1.0.0 f6fd8000-f6fd9000 r--p 00000000 fd:01 201522922 /usr/lib/libxshmfence.so.1.0.0 f6fd9000-f6fda000 rw-p 00001000 fd:01 201522922 /usr/lib/libxshmfence.so.1.0.0 f6fda000-f6ffd000 r-xp 00000000 fd:01 202740769 /usr/lib/libxcb.so.1.1.0 f6ffd000-f6ffe000 r--p 00022000 fd:01 202740769 /usr/lib/libxcb.so.1.1.0 f6ffe000-f6fff000 rw-p 00023000 fd:01 202740769 /usr/lib/libxcb.so.1.1.0 f6fff000-f7004000 r-xp 00000000 fd:01 201522899 /usr/lib/libxcb-sync.so.1.0.0 f7004000-f7005000 r--p 00005000 fd:01 201522899 /usr/lib/libxcb-sync.so.1.0.0 f7005000-f7006000 rw-p 00006000 fd:01 201522899 /usr/lib/libxcb-sync.so.1.0.0 f7006000-f7009000 r-xp 00000000 fd:01 201522895 /usr/lib/libxcb-shape.so.0.0.0 f7009000-f700a000 r--p 00002000 fd:01 201522895 /usr/lib/libxcb-shape.so.0.0.0 f700a000-f700b000 rw-p 00003000 fd:01 201522895 /usr/lib/libxcb-shape.so.0.0.0 f700b000-f7014000 r-xp 00000000 fd:01 201522889 /usr/lib/libxcb-render.so.0.0.0 f7014000-f7015000 r--p 00008000 fd:01 201522889 /usr/lib/libxcb-render.so.0.0.0 f7015000-f7016000 rw-p 00009000 fd:01 201522889 /usr/lib/libxcb-render.so.0.0.0 f7016000-f701d000 r-xp 00000000 fd:01 201522905 /usr/lib/libxcb-xfixes.so.0.0.0 f701d000-f701e000 r--p 00006000 fd:01 201522905 /usr/lib/libxcb-xfixes.so.0.0.0 f701e000-f701f000 rw-p 00007000 fd:01 201522905 /usr/lib/libxcb-xfixes.so.0.0.0 f701f000-f702c000 r-xp 00000000 fd:01 201522885 /usr/lib/libxcb-randr.so.0.1.0 f702c000-f702d000 r--p 0000d000 fd:01 201522885 /usr/lib/libxcb-randr.so.0.1.0 f702d000-f702e000 rw-p 0000e000 fd:01 201522885 /usr/lib/libxcb-randr.so.0.1.0 f702e000-f7030000 r-xp 00000000 fd:01 201522883 /usr/lib/libxcb-present.so.0.0.0 f7030000-f7031000 r--p 00001000 fd:01 201522883 /usr/lib/libxcb-present.so.0.0.0 f7031000-f7032000 rw-p 00002000 fd:01 201522883 /usr/lib/libxcb-present.so.0.0.0 f7032000-f7034000 r-xp 00000000 fd:01 203140423 /usr/lib/libxcb-dri3.so.0.0.0 f7034000-f7035000 r--p 00001000 fd:01 203140423 /usr/lib/libxcb-dri3.so.0.0.0 f7035000-f7036000 rw-p 00002000 fd:01 203140423 /usr/lib/libxcb-dri3.so.0.0.0 f7036000-f703a000 r-xp 00000000 fd:01 203140421 /usr/lib/libxcb-dri2.so.0.0.0./pharo-ui: line 11: 4019 Aborted (core dumped) "$DIR"/"pharo-vm/pharo" "$@" -- Mariano http://marianopeck.wordpress.com

7 15

Idea to improve GTInspector
by stepharo Jan. 9, 2016

Jan. 9, 2016

We cannot see the class definition when browsing a collection of classes.

2 1

Semaphore and Mutex changes summary
by Denis Kudriashov Jan. 9, 2016

Jan. 9, 2016

Hi. We got interesting discussion about semaphore and mutex. Here I put summary of proposed changes. First we will deprecate Semaphore>>forMutualExclusion and rename it to Semaphore>>newSignalled. Explanation from Ben Coman: Semaphore>>forMutualExclusion *encourages* people to believe > semaphores can be used *on*their*own* for mutual exclusion, when they > *shouldn't*. You *must* add ownership. If the mutual exclusion > object doesnât have ownership then, irrelevant of what it is called, > it is not a mutex!!! [1]. And more: > With an implementation like.. > Semaphore>>forMutualExclusion > ^self new signal > we don't gain a lot, and its a misleading convenience method since its > doesn't provide the proper facility for mutual exclusion (and I do > conflate mutual exclusion == mutex). Indeed, "Semaphore > forMutualExclusion + roll your ownership management + problems since > you weren't aware you needed to roll your own ownership management" is > not more convenient than "Mutex new" > If you want to keep a convenience method for a pre signalled > Semaphore, then we could provide something like "Semaphore > newSignalled" It is also explain why we should deprecate Semaphore>>critical: and use Mutex>>critical: instead. That's second change. So we want to move 4 Semaphore methods to Mutex: - critical: mutuallyExcludedBlock It will relies on new Semaphore method waitIfInterrupted: which block is executed when waiting process terminated at point where lock was not acquired. Slice for this already in inbox. - critical: mutuallyExcludedBlock ifCurtailed: terminationBlock - critical: mutuallyExcludedBlock ifError: errorBlock Semantic of this method is like BlockCosure>>ifError:. It culls error properties to handler block. It will be changed to cull only error instance. It will touch WeakArray and WeakRegistry. Now they doing this: ifError:[:msg :rcvr| rcvr error: msg]. No special logic inside handler. So we will just use #critical: message. - critical: mutuallyExcludedBlock ifLocked: alternativeBlock It purpose looks like "enter critical section without waiting otherwise alternativeBlock". But implementation not shows that waiting can not be happens: critical: mutuallyExcludedBlock ifLocked: alternativeBlock excessSignals == 0 ifTrue: [ ^alternativeBlock value ]. ^self critical: mutuallyExcludedBlock When critical message is sent but it method not started interrupt can happen and other process can lock this semaphore. And when process will be resumed it will be blocked. So implementation is not correct to me. It should be changed somehow. Welcome for suggestions

3 4