- Pharo-dev - lists.pharo.org

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

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

by Dimitris Chloupis

yes you are correct, keeping the copyright list in is the requirement pretty much of any license. to make sure that is not a transfer of copyright but rather what it really is, a license , to use the code as you wish. Frankly as a lawyere I dont care, this is open source, code is modified all the time. how you make sure your copyright is intact ? you cant. Its not clear cut case, and the moment someone modifies your code he creates his own copyright on the code he modified. And then even if you want to go to the court over this the burden of proof will be on you to prove how much copyright you have over the code and exactly which parts. Obviously if the code is not modified at all , at least the part you claiming copyright for , and you can prove it that is yours beyond reasonable doubt then you are fine, though you will still have to go to the court to defend and suffer all the expenses and pain that equates. But if the code is modified , you fight a lost cause , because we have mix of copyrights in that case and all hell brakes loose. The only way to guaranty copyright is to keep the source closed and under a strict license which what the vast majority of companies are doing and should be doing. Especially for code they deeply care to keep a copyright of. Open source is a copyright minefield and this is why its not very viable financially and companies dont like it, when copyright itself is their lifehood. On Fri, Jan 8, 2016 at 6:09 PM 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. > > 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] GTDebugger (case 17341 Integrate GTools version 3.3)

by Esteban Lorenzano

> On 08 Jan 2016, at 17:04, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > > 2016-01-08 12:48 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>>: > > > > On 08 Jan 2016, at 16:43, Andrei Chis <chisvasileandrei(a)gmail.com <mailto:chisvasileandrei@gmail.com>> wrote: > > > > 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 <mailto:nicolaihess@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â > > +1 to this, I had to hover it to realize it. > > The best icons I found for these features are the ones from Dolphin Smalltalk (now opensourced ;-) ) > > <dolphin-dbg.png> they are more or less equal. also we will not mix button sets :) > > > > for me they are not small, but misplaced. I expect to have them close to > > where Iâm looking for: the code (that happens in all debuggers I know, with > > the exception of ddd who opens a different window). > > For me, they should be in the code panel and not in the stack panel. > > alsoâ¦ shortcuts do not work in code panel :( > > +1 to this. Altough if you use shortcuts you don't care where they are located. yes you careâ¦ I use both :) > > BTW, is it possible to use the function keys as shortcuts? I would map F10-F12 (with modifiers) as shortcuts. thatâs not possibleâ¦ they are taken by O.S. usually. Esteban > > Regards! > > > Esteban A. Maringolo

Jan. 8, 2016

Question about attribution under the MIT License

by Sven Van Caekenberghe

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

[pharo-project/pharo-core]

by GitHub

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

Jan. 8, 2016

[pharo-project/pharo-core] 2354ee: 50519

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: 2354ee435aa2ae08cbc362bd26432a25d56150c2 https://github.com/pharo-project/pharo-core/commit/2354ee435aa2ae08cbc362bd… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-01-08 (Fri, 08 Jan 2016) Changed paths: A Deprecated50.package/extension/Object/instance/haltIfShiftPressed.st M Kernel.package/CompiledMethod.class/instance/testing/containsHalt.st R Kernel.package/Object.class/instance/halting/haltIfShiftPressed.st M Nautilus.package/MethodContainsHaltAction.class/instance/order/isActionHandled.st R NautilusCommon.package/extension/RGMethodDefinition/instance/containsHalt.st M OpalCompiler-Core.package/IRBytecodeGenerator.class/definition.st M OpalCompiler-Core.package/IRBytecodeGenerator.class/instance/private/nextPut_.st M OpalCompiler-Core.package/IRBytecodeGenerator.class/instance/results/bytecodes.st M OpalCompiler-Core.package/IRBytecodeGenerator.class/instance/results/compiledMethodWith_.st M OpalCompiler-Core.package/IRBytecodeGenerator.class/instance/results/endPrimNumber.st M OpalCompiler-Core.package/IRBytecodeGenerator.class/instance/results/hasPrimitive.st A Ring-Core-Kernel.package/RGMethodDefinition.class/instance/testing/containsHalt.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50518.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50519.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50518.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50519.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50519 17251 Quick method primitive not set correctly for #spurVMHeader: https://pharo.fogbugz.com/f/cases/17251 17346 move #haltIfShiftPressed to Deprecated50 https://pharo.fogbugz.com/f/cases/17346 http://files.pharo.org/image/50/50519.zip

Jan. 8, 2016