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

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

Re: [Pharo-dev] Adapting the launcher to Spur VM

by Ferlicot D. Cyril

Le 08/01/2016 16:45, Esteban A. Maringolo a Ã©crit : > Was this fixed? > > I downloaded the latest 5.0 image and also the Moose gttoolkit5 > images, and I can't start them, the launcher closes without any > further notification. > > My previous 5.0 image (from Dec/10th 2015) starts normally. > > It would be great to have a two lines list of the images, one with the > name/description, and other subline with the image version and vm > version. :) > > Where can I get the source of the launcher itself? > > Regards! > > > Esteban A. Maringolo > > Hi, The launcher is fix but there is no stable version for now. You have to update it from Monticello then you change the path on Spur VM in the settings. -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Jan. 8, 2016

Re: [Pharo-dev] GTDebugger (case 17341 Integrate GTools version 3.3)

by Esteban A. Maringolo

2016-01-08 12:48 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 08 Jan 2016, at 16:43, Andrei Chis <chisvasileandrei(a)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> 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 ;-) ) [image: ImÃ¡genes integradas 1] > > 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. BTW, is it possible to use the function keys as shortcuts? I would map F10-F12 (with modifiers) as shortcuts. Regards! Esteban A. Maringolo

Jan. 8, 2016

Re: [Pharo-dev] GTDebugger (case 17341 Integrate GTools version 3.3)

by Esteban Lorenzano

> On 08 Jan 2016, at 16:43, Andrei Chis <chisvasileandrei(a)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â 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 :( Esteban > - the shortcuts (neither ctrl+t nor cmd+t) aren't working > - I find it totally annoying and useless that the context pane inspector scrolls away if you select a value in > the rightmost pane. The context inspector should be fixed. > - I really miss the "List Methods using 'varname'/List Methods storing into 'varname' > - the stacklist entry for block closures prints the block closure code, this is confusing (too much text for such a small widget). > > nicolai >

Jan. 8, 2016

Re: [Pharo-dev] Adapting the launcher to Spur VM

by Esteban A. Maringolo

Was this fixed? I downloaded the latest 5.0 image and also the Moose gttoolkit5 images, and I can't start them, the launcher closes without any further notification. My previous 5.0 image (from Dec/10th 2015) starts normally. It would be great to have a two lines list of the images, one with the name/description, and other subline with the image version and vm version. :) Where can I get the source of the launcher itself? Regards! Esteban A. Maringolo 2015-12-17 18:11 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: > On 17/12/15 22:04, David T. Lewis wrote: >>> >>> On 17-12-15 18:21, Eliot Miranda wrote: >>>> >>>> Hi Stephan, >>>> >>>> I love you too ;-). Just in case you weren't aware David Lewis' >>>> ImageFormat package on http://source.squeak.org/VMMaker contains the >>>> "official" approach to image version ids and will provide you with "the >>>> official way" (tm) to test for a Spur image, including 64-bits. >>> >>> >>> Ah, there is a lot more to do than testing for 6505, I see. >>> I suspect ImageFormat needs an update, the last version is from 2011 and >>> Spur is suspiciously missing. I'll add that instead. >>> >>> Stephan >>> >> >> Make sure you got the latest version from the repository, it should be >> fully up to date, including the image format info for the 64-bit Spur >> image. > > > Ah, that is not the same as squeaksource.com ... > My mistake > > Stephan > >

Jan. 8, 2016

Re: [Pharo-dev] GTDebugger (case 17341 Integrate GTools version 3.3)

by Andrei Chis

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> 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" > - the shortcuts (neither ctrl+t nor cmd+t) aren't working > - I find it totally annoying and useless that the context pane inspector > scrolls away if you select a value in > the rightmost pane. The context inspector should be fixed. > - I really miss the "List Methods using 'varname'/List Methods storing > into 'varname' > - the stacklist entry for block closures prints the block closure code, > this is confusing (too much text for such a small widget). > > nicolai >

Jan. 8, 2016