January 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Question about attribution under the MIT License

by monty

This line form the text of the license suggests we should really be bundling the full license text with our code, not just stating "this code is MIT" on the STH project page: "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software." Because of this, I've started adding #catalogLicense methods to STH Configs I manage that return the entire MIT license text with a copyright statement. I think everyone should do the same. > Sent: Friday, January 08, 2016 at 11:08 AM > From: "Sven Van Caekenberghe" <sven(a)stfx.eu> > To: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Subject: [Pharo-dev] Question about attribution under the MIT License > > Hi, > > I have a been wondering recently about attribution under the MIT License. > > Code in Pharo and code contributed to Pharo is and should be licensed under the MIT License. > > https://en.wikipedia.org/wiki/MIT_License > > Contributors sign an extra agreement. > > http://files.pharo.org/media/PharoSoftwareDistributionAgreement.pdf > > Here, contributors give a license so Pharo can include their code. > > As I read the MIT license the original author keeps the copyright and about the only requirement is that that copyright shall be included when the code is used. The extra agreement does not transfer copyright. > > So, all authors should be mentioned in the general Pharo MIT license. > > The reason I was thinking about this is that many people on the list seems to be under the impression that MIT licensed code means that you can freely copy it, like most recently in the discussions about Dophin Smalltalk. I think copying MIT licensed code requires proper attribution. > > If people copy (my, someone else's) code from Pharo to somewhere else, I want them to at least acknowledge that fact, preferably include a general Pharo (contributors) copyright, but ideally (my, their) copyright. > > But that would also mean that Pharo has to do the same. I think we should list and update the official contributor list, including the historical list of original authors going back. > > Am I right or wrong ? > > How do other people feel about this ? > > Sven > > >

Jan. 8, 2016

Re: [Pharo-dev] Help with FFI crash in latest Spur (only in Linux)

by Max Leske

> On 08 Jan 2016, at 19:35, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Fri, Jan 8, 2016 at 3:04 PM, Mariano Martinez Peck <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: > 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 <http://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 <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. > > > If I change above line with this: > > posixSpawnFileActionsT := ByteArray new: 4. Wil this not allocate more the four bytes because of the object header? So how about allocating 8 bytes for the pointer (just for fun)? ExternalAddress allocate: 8 > > Then the function does not crash but it crashes in the future posix_spawn_file_actions_destroy(). > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>

Jan. 8, 2016

Re: [Pharo-dev] Help with FFI crash in latest Spur (only in Linux)

by Mariano Martinez Peck

On Fri, Jan 8, 2016 at 3:04 PM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > 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. > If I change above line with this: posixSpawnFileActionsT := ByteArray new: 4. Then the function does not crash but it crashes in the future posix_spawn_file_actions_destroy(). -- Mariano http://marianopeck.wordpress.com

Jan. 8, 2016

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

by Johan Fabry

I second Torstenâs comment with regard to the use of space, I also think the original positioning of stack and code panes is more efficient. > On Jan 8, 2016, at 14:28, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi, > > with a moldable debugger we should (in the future) be able to support > debugging also different/other programming languages/DSLs in Pharo :) > - although usually one does necessary have such a use case. So I guess > GTInspector or other will be adopted to own needs more than GTDebugger. > > However: > The only objection so far is that I dislike the order/size of the panes. > The placement of the panes in GTDebugger (as for instance found in Moose) > requires often to use the scrollbars of the pane showing the stack because > of the text length. > > In GTDebugger the stack is at the top left, the source at the top right with > a common splitter beneath the two panes: therefore the height (depth) of the > stack pane is always the height of the code pane. > When you have a long method to debug on the right much space is wasted for > a deep stack on the left although you might only be interested in a few top frames. > > Contrary when you have are interested in a deep/full stack and you increase the > height of the stack pane on the left you directly increase the height of the code > pane and for short methods you waste a lot of space in the source pane as well. > > This is much better solved with the positioning in the traditinal Debugger: > - Stack > - Source > - other > > So in my opinion We should preserve: > > - TOP: the stack at the top (using the full width of the window, so only vertical scrolling > has to be done to "roll" on the stack, no need for horizontal scrolling as the area > is wide enough) > - MIDDLE: the source code pane in the middle (also using the full width of the window and there > fore in alignment with code pane in the the usual tools like Nautilus, change sorter, ...) > - BOTTON: one or more panel for inspection at the bottom > > It would be OK for me if others like the new layout better - but at least there should be an > option to support the traditional layout as well (or support pane movemen/docking as in other IDEs) > > Also the debugger window in Moose wastes a lot of space/has unused space within the > windows client are itself. For instance the splitters are very thick which might be an issue of > the moose theme. > > Thanks > T. > > Gesendet: Freitag, 08. Januar 2016 um 11:24 Uhr > Von: "Tudor Girba" <tudor(a)tudorgirba.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org>, "Moose-dev Moose Dev" <moose-dev(a)iam.unibe.ch>, "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> > Betreff: [Pharo-dev] [ann] gtdebugger in pharo 5.0 > > 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). > > > > Here is 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[http://www.feenk.com] > > "Beauty is where we see it." ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

Jan. 8, 2016

Help with FFI crash in latest Spur (only in Linux)

by Mariano Martinez Peck

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

Jan. 8, 2016

Re: [Pharo-dev] [squeak-dev] Re: [Vm-dev] Where to get Monitor implementation based on primitives?

by Denis Kudriashov

Now I implement pragma approach to set up local variable during termination process. So I can write such methods: critical: aBlock "Evaluate aBlock protected by the receiver." | lockAcquired | <lockAt: #lock trackStateAt: 1> lockAcquired := false. ^[ lockAcquired := true. lockAcquired := lock wait. aBlock value ] ensure: [lockAcquired ifTrue: [lock signal]]. And Process>>terminate detects waiting on such methods and push false to variable lockAcquired (which is 1 temp here). This approach allow me to use multiple "locks" (semaphores or whatever) in single method which I need for ReadWriteLock. 2016-01-08 18:31 GMT+01:00 Eliot Miranda <eliot.miranda(a)gmail.com>: > Hi Ben, > > On Thu, Jan 7, 2016 at 4:40 PM, Ben Coman <btc(a)openinworld.com> wrote: > >> On Fri, Jan 8, 2016 at 2:51 AM, Eliot Miranda <eliot.miranda(a)gmail.com> >> wrote: >> > Hi Ben, >> > >> > On Thu, Jan 7, 2016 at 10:39 AM, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> >> >> >> On Fri, Jan 8, 2016 at 1:20 AM, Eliot Miranda <eliot.miranda(a)gmail.com >> > >> >> wrote: >> >> > >> >> > and here's a version with a better class comment >> >> > >> >> > On Thu, Jan 7, 2016 at 9:12 AM, Eliot Miranda < >> eliot.miranda(a)gmail.com> >> >> > wrote: >> >> >> >> >> >> Hi Denis, Hi ClÃ©ment, Hi Frank, >> >> >> >> >> >> On Thu, Jan 7, 2016 at 5:34 AM, ClÃ©ment Bera < >> bera.clement(a)gmail.com> >> >> >> wrote: >> >> >>> >> >> >>> Hello, >> >> >>> >> >> >>> Eliot, please, you told me you had the code and Denis is >> interested. >> >> >>> >> >> >>> It uses 3 primitives for performance. >> >> >> >> >> >> >> >> >> Forgive the delay. I thought it proper to ask permission since the >> >> >> code was written while I was at Qwaq. I'm attaching the code in a >> fairly raw >> >> >> state, see the attached. The code is MIT, but copyright 3DICC. >> >> >> >> >> >> It is a plugin replacement for Squeak's Mutex, and with a little >> >> >> ingenuity could be a replacement for Squeak's Monitor. It is >> quicker >> >> >> because it uses three new primitives to manage entering a critical >> section >> >> >> and setting the owner, exiting the critical section and releasing >> the owner, >> >> >> and testing if a critical section, entering if the section is >> unowned. The >> >> >> use of the primitives means fewer block activations and ensure: >> blocks in >> >> >> entering and exiting the critical section, and that's the actual >> cause of >> >> >> the speed-up. >> >> >> >> >> >> You can benchmark the code as is. Here are some results on 32-bit >> >> >> Spur, on my 2.2GHz Core i7 >> >> >> >> >> >> {Mutex new. Monitor new. CriticalSection new} collect: >> >> >> [:cs| | n | >> >> >> n := 0. >> >> >> [cs critical: [n := n + 1]. cs critical: [n := n + 1]. cs critical: >> [n >> >> >> := n + 1]. cs critical: [n := n + 1]. cs critical: [n := n + 1]. >> >> >> cs critical: [n := n - 1]. cs critical: [n := n - 1]. cs critical: >> [n >> >> >> := n - 1]. cs critical: [n := n - 1]. cs critical: [n := n - 1]. >> >> >> n ] bench] >> >> >> >> >> >> {Mutex new. Monitor new. CriticalSection new} collect: >> >> >> [:cs| | n | >> >> >> n := 0. >> >> >> cs class name, ' -> ', >> >> >> [cs critical: [n := n + 1]. cs critical: [n := n + 1]. cs critical: >> [n >> >> >> := n + 1]. cs critical: [n := n + 1]. cs critical: [n := n + 1]. >> >> >> cs critical: [n := n - 1]. cs critical: [n := n - 1]. cs critical: >> [n >> >> >> := n - 1]. cs critical: [n := n - 1]. cs critical: [n := n - 1]. >> >> >> n ] bench] >> >> >> >> >> >> #( 'Mutex -> 440,000 per second. 2.27 microseconds per run.' >> >> >> 'Monitor -> 688,000 per second. 1.45 microseconds per run.' >> >> >> 'CriticalSection -> 1,110,000 per second. 900 nanoseconds per run.') >> >> >> >> >> >> >> This is great Eliot. Thank you and 3DICC. After loading the changeset >> >> into Pharo-50515 (32 bit Spur) I get the following results on my >> >> laptop i5-2520M @ 2.50GHz >> >> >> >> #('Mutex -> 254,047 per second' >> >> 'Monitor -> 450,442 per second' >> >> 'CriticalSection -> 683,393 per second') >> >> >> >> In a fresh Image "Mutex allInstances basicInspect" lists just two >> >> mutexes... >> >> 1. NetNameResolver-->ResolverMutex >> >> 2. ThreadSafeTranscript-->accessSemaphore >> > >> > >> > I hate myself for getting distracted but I'm finding this is un. One >> can >> > migrate to the new representation using normal Monticello loads by >> > >> > In the first version redefine Mutex and Monitor to subclass LinkedList >> and >> > have their owner/ownerProcess inst var first (actually third after >> firstLink >> > & lastLink), and add the primitives. >> > >> > In the next version check that all Mutex and Monitor instanes are >> unowned >> > and then redefine to discard excess inst vars >> > >> > Let me test this before committing, and see that all tests are ok. >> >> Should Mutex and Monitor both directly subclass LinkedList and >> duplicate the primitives in each? >> >> Or should they both subclass CriticalSection which subclasses >> LinkedList so the primitives are only defined once? >> > > That's a good idea. Feel free to change the code, but test that the > Monticello load handles this case properly first :-). Actually, given that > the default state of all the Mutex and Monitor instances in the image is > unowned (owner process is nil) then it'll just work anyway. If we do that, > we must make sure to include the ICC copyright in CriticalSection's class > comment, and can eliminate it from the primitives. > > What effect would using the primitives from the superclass have on >> performance? If any, I'd vote to optimise for duplication rather than >> "nice" design, but our comments should document this. >> > > Likely in the noise. The inline cacheing machinery in the VM is far > cheaper than the real overheads here which are in block creation, process > switch, interpreter primitive invocation. > > >> >> cheers -ben >> >> > > > -- > _,,,^..^,,,_ > best, Eliot > > > >

Jan. 8, 2016

Re: [Pharo-dev] Question about attribution under the MIT License

by Ben Coman

On Sat, Jan 9, 2016 at 12:08 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > I have a been wondering recently about attribution under the MIT License. > > Code in Pharo and code contributed to Pharo is and should be licensed under the MIT License. > > https://en.wikipedia.org/wiki/MIT_License > > Contributors sign an extra agreement. > > http://files.pharo.org/media/PharoSoftwareDistributionAgreement.pdf > > Here, contributors give a license so Pharo can include their code. > > As I read the MIT license the original author keeps the copyright and about the only requirement is that that copyright shall be included when the code is used. The extra agreement does not transfer copyright. > > So, all authors should be mentioned in the general Pharo MIT license. > > The reason I was thinking about this is that many people on the list seems to be under the impression that MIT licensed code means that you can freely copy it, like most recently in the discussions about Dophin Smalltalk. I think copying MIT licensed code requires proper attribution. The MIT license allows you to sub-license, so technically I guess you could re-license it to someone (or back to yourself) with the attribution requirement removed. But that would be really be bad form. Eric Raymond says it well [1]: "the Lockean property customs of hackerdom are a means of maximizing reputation incentives; of ensuring that peer credit goes where it is due and does not go where it is not due. ... Surreptitiously filing someone's name off a project is, in cultural context, one of the ultimate crimes. Doing this steals the victim's gift to be presented as the thief's own. [1] http://catb.org/~esr/writings/homesteading/homesteading/ar01s09.html > If people copy (my, someone else's) code from Pharo to somewhere else, I want them to at least acknowledge that fact, preferably include a general Pharo (contributors) copyright, but ideally (my, their) copyright. > > But that would also mean that Pharo has to do the same. I think we should list and update the official contributor list, including the historical list of original authors going back. > > Am I right or wrong ? > > How do other people feel about this ? I agree with you. Paying attention to this sort of thing builds community trust and involvement. cheers -ben

Jan. 8, 2016

Re: [Pharo-dev] [squeak-dev] Re: [Vm-dev] Where to get Monitor implementation based on primitives?

by Eliot Miranda

Hi Ben, On Thu, Jan 7, 2016 at 4:40 PM, Ben Coman <btc(a)openinworld.com> wrote: > On Fri, Jan 8, 2016 at 2:51 AM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > Hi Ben, > > > > On Thu, Jan 7, 2016 at 10:39 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> > >> > >> On Fri, Jan 8, 2016 at 1:20 AM, Eliot Miranda <eliot.miranda(a)gmail.com> > >> wrote: > >> > > >> > and here's a version with a better class comment > >> > > >> > On Thu, Jan 7, 2016 at 9:12 AM, Eliot Miranda < > eliot.miranda(a)gmail.com> > >> > wrote: > >> >> > >> >> Hi Denis, Hi ClÃ©ment, Hi Frank, > >> >> > >> >> On Thu, Jan 7, 2016 at 5:34 AM, ClÃ©ment Bera <bera.clement(a)gmail.com > > > >> >> wrote: > >> >>> > >> >>> Hello, > >> >>> > >> >>> Eliot, please, you told me you had the code and Denis is interested. > >> >>> > >> >>> It uses 3 primitives for performance. > >> >> > >> >> > >> >> Forgive the delay. I thought it proper to ask permission since the > >> >> code was written while I was at Qwaq. I'm attaching the code in a > fairly raw > >> >> state, see the attached. The code is MIT, but copyright 3DICC. > >> >> > >> >> It is a plugin replacement for Squeak's Mutex, and with a little > >> >> ingenuity could be a replacement for Squeak's Monitor. It is quicker > >> >> because it uses three new primitives to manage entering a critical > section > >> >> and setting the owner, exiting the critical section and releasing > the owner, > >> >> and testing if a critical section, entering if the section is > unowned. The > >> >> use of the primitives means fewer block activations and ensure: > blocks in > >> >> entering and exiting the critical section, and that's the actual > cause of > >> >> the speed-up. > >> >> > >> >> You can benchmark the code as is. Here are some results on 32-bit > >> >> Spur, on my 2.2GHz Core i7 > >> >> > >> >> {Mutex new. Monitor new. CriticalSection new} collect: > >> >> [:cs| | n | > >> >> n := 0. > >> >> [cs critical: [n := n + 1]. cs critical: [n := n + 1]. cs critical: > [n > >> >> := n + 1]. cs critical: [n := n + 1]. cs critical: [n := n + 1]. > >> >> cs critical: [n := n - 1]. cs critical: [n := n - 1]. cs critical: [n > >> >> := n - 1]. cs critical: [n := n - 1]. cs critical: [n := n - 1]. > >> >> n ] bench] > >> >> > >> >> {Mutex new. Monitor new. CriticalSection new} collect: > >> >> [:cs| | n | > >> >> n := 0. > >> >> cs class name, ' -> ', > >> >> [cs critical: [n := n + 1]. cs critical: [n := n + 1]. cs critical: > [n > >> >> := n + 1]. cs critical: [n := n + 1]. cs critical: [n := n + 1]. > >> >> cs critical: [n := n - 1]. cs critical: [n := n - 1]. cs critical: [n > >> >> := n - 1]. cs critical: [n := n - 1]. cs critical: [n := n - 1]. > >> >> n ] bench] > >> >> > >> >> #( 'Mutex -> 440,000 per second. 2.27 microseconds per run.' > >> >> 'Monitor -> 688,000 per second. 1.45 microseconds per run.' > >> >> 'CriticalSection -> 1,110,000 per second. 900 nanoseconds per run.') > >> >> > >> > >> This is great Eliot. Thank you and 3DICC. After loading the changeset > >> into Pharo-50515 (32 bit Spur) I get the following results on my > >> laptop i5-2520M @ 2.50GHz > >> > >> #('Mutex -> 254,047 per second' > >> 'Monitor -> 450,442 per second' > >> 'CriticalSection -> 683,393 per second') > >> > >> In a fresh Image "Mutex allInstances basicInspect" lists just two > >> mutexes... > >> 1. NetNameResolver-->ResolverMutex > >> 2. ThreadSafeTranscript-->accessSemaphore > > > > > > I hate myself for getting distracted but I'm finding this is un. One can > > migrate to the new representation using normal Monticello loads by > > > > In the first version redefine Mutex and Monitor to subclass LinkedList > and > > have their owner/ownerProcess inst var first (actually third after > firstLink > > & lastLink), and add the primitives. > > > > In the next version check that all Mutex and Monitor instanes are unowned > > and then redefine to discard excess inst vars > > > > Let me test this before committing, and see that all tests are ok. > > Should Mutex and Monitor both directly subclass LinkedList and > duplicate the primitives in each? > > Or should they both subclass CriticalSection which subclasses > LinkedList so the primitives are only defined once? > That's a good idea. Feel free to change the code, but test that the Monticello load handles this case properly first :-). Actually, given that the default state of all the Mutex and Monitor instances in the image is unowned (owner process is nil) then it'll just work anyway. If we do that, we must make sure to include the ICC copyright in CriticalSection's class comment, and can eliminate it from the primitives. What effect would using the primitives from the superclass have on > performance? If any, I'd vote to optimise for duplication rather than > "nice" design, but our comments should document this. > Likely in the noise. The inline cacheing machinery in the VM is far cheaper than the real overheads here which are in block creation, process switch, interpreter primitive invocation. > > cheers -ben > > -- _,,,^..^,,,_ best, Eliot

Jan. 8, 2016

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

by Torsten Bergmann

Hi, with a moldable debugger we should (in the future) be able to support debugging also different/other programming languages/DSLs in Pharo :) - although usually one does necessary have such a use case. So I guess GTInspector or other will be adopted to own needs more than GTDebugger. However: The only objection so far is that I dislike the order/size of the panes. The placement of the panes in GTDebugger (as for instance found in Moose) requires often to use the scrollbars of the pane showing the stack because of the text length. In GTDebugger the stack is at the top left, the source at the top right with a common splitter beneath the two panes: therefore the height (depth) of the stack pane is always the height of the code pane. When you have a long method to debug on the right much space is wasted for a deep stack on the left although you might only be interested in a few top frames. Contrary when you have are interested in a deep/full stack and you increase the height of the stack pane on the left you directly increase the height of the code pane and for short methods you waste a lot of space in the source pane as well. This is much better solved with the positioning in the traditinal Debugger: - Stack - Source - other So in my opinion We should preserve: - TOP: the stack at the top (using the full width of the window, so only vertical scrolling has to be done to "roll" on the stack, no need for horizontal scrolling as the area is wide enough) - MIDDLE: the source code pane in the middle (also using the full width of the window and there fore in alignment with code pane in the the usual tools like Nautilus, change sorter, ...) - BOTTON: one or more panel for inspection at the bottom It would be OK for me if others like the new layout better - but at least there should be an option to support the traditional layout as well (or support pane movemen/docking as in other IDEs) Also the debugger window in Moose wastes a lot of space/has unused space within the windows client are itself. For instance the splitters are very thick which might be an issue of the moose theme. Â Thanks T.Â Gesendet:Â Freitag, 08. Januar 2016 um 11:24 Uhr Von:Â "Tudor Girba" <tudor(a)tudorgirba.com> An:Â "Pharo Development List" <pharo-dev(a)lists.pharo.org>, "Moose-dev Moose Dev" <moose-dev(a)iam.unibe.ch>, "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> Betreff:Â [Pharo-dev] [ann] gtdebugger in pharo 5.0 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). Â Â Here is 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[http://www.feenk.com] "Beauty is where we see it." Â

Jan. 8, 2016

Re: [Pharo-dev] Atomic commits

by Dimitris Chloupis

When one uses a tool in a way that is not suppose to use , the one must expect all sort of new and fascinating problems. Some think that putting changes in 2121 files in a single commit is a good idea, github politely disagrees. In this case if you want go down the visual route I highly recommend a Git GUI client, I know people are obsessed of doing everything inside pharo, something I may never understand but as I stated in my video tutorial about Git , nothing pharo will create at least the next year will come remotely close to the elegant workflow of some of the best GIT GUIs like SmartGit, SourceTree and lately I am deeply in love with GitUp which unfortunately is only for MacOS because I think is awesome git gui client that makes git super easy. Most coders that use git rely on a git client of some sort, if you dont like guis and prefer emacs, there is also magit that i hear is very good. No disrespect on people working on git integration in pharo, I am 100% behind them, but frankly I rather use pharo with other tools than pharo alone and try to convince myself that my old methods are going to work with new external tools. On Wed, Jan 6, 2016 at 8:14 PM Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > Hi, > I wish the commits were much more atomic than they currently are... > With current practice, reviewing the changes is near to impossible: > - it requires far too much concentration > - it's just impossible through github web interface > > For example, I did wander if the structure fields were correclty aligned > in: > > https://github.com/pharo-project/pharo-core/blame/5986a695fb28834247a90dbf8… > because I see no code for aligning the offsets... > > But I cannot even navigate in the history... If I do so, > > https://github.com/pharo-project/pharo-core/commit/dfd4f3ae0f0b0af7766c1405… > the page tells me > "Sorry, we could not display the entire diff because too many files > (2,121) changed" > and I couldn't find a way of displaying the portion of interest. > > I thus loose the ability to deposit a comment. > > I can still open a fresh Pharo image and browse and review the whole code > snapshot there. > Or I can navigate more easily in history with git tools. > But if I wanted a lightweight review thru web, focusing on the diffs and > navigating a bit in history without replicating the repository, I can't. > > While ranting, it's nice to have the commits performed by a jenkins > server, but how do we track the authors of original modifications? > In a normal git based development, there would be feature branches > integrated/merged in trunk/master by whatever process. > But in current process i fail to capture such information... > > This gives a taste of under-powered use of the tools, and I wander if > being visible in these conditions is a good thing: we don't expose the best > practices. >

Jan. 8, 2016