- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] License agreement - are you kidding me?

by Sven Van Caekenberghe

I don't want to add to this discussion, but when plain errors are written, I have to. I thought you were a lawyer ? http://files.pharo.org/media/PharoSoftwareDistributionAgreement.pdf << The Parties agree that Supplier has contributed source code (the âSupplierâs Codeâ) for the open source software known as âPharoâ (the âSoftwareâ), and that Supplier retains all rights in and to Supplierâs Code, aside from the rights expressly granted to Distributor in this Agreement. The Parties acknowledge that the Software in its entirety is a collective work containing source code contributions from several authors, and that Supplierâs Code is only a small component part of the Software work as a whole. Supplier hereby grants Distributor a perpetual, irrevocable, non-exclusive, royalty-free, worldwide license to distribute the Software, and specifically the Supplierâs Code therein, to end users, subject to the license agreement commonly known as the âMIT Licenseâ >> Nowhere it says that you lose your copyright !! Furthermore, this is a very simple document with no hidden agenda, it is a consequence of using the MIT license. > On 08 Dec 2015, at 10:54, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > The one thing I dont like about that agreement is that it forces to retreat from the personal copyright if I remember the document correctly. Even though personally I would not mind that for bug fixes and small enhancements where my copyright would not be so much of a big deal. For bigger tools and code that I have put substantial effort and suffered pain to make them work I would not give away my copyright. So I am not seeing myself signing this any time soon either. > > Revealing my real name and some other stuff is not a problem. > > So I can certainly understand some of your frustration webwarrior. > > > > On Tue, Dec 8, 2015 at 10:44 AM phil(a)highoctane.be <phil(a)highoctane.be> wrote: > On Tue, Dec 8, 2015 at 12:47 AM, webwarrior <reg(a)webwarrior.ws> wrote: > Considering that there are a couple of responses and the fact that you > guys are so easily offended, I will not answer everyone but just state > couple of theses. > > > 0. I will not reveal my real name, because I value privacy. Nickname is > sufficient for identification purposes. Any other information (real > name, address, etc.) is not needed for actually contributing code. Think > of principle of least privilege. > > 1. I could easily make up some human-looking name (Satoshi Nakamoto > anyone?), but will not do it out of principle (see #0). > > 2. Knowing contributor's "real" name would not guard you against any > possible malicious actions from him, because it can't be verified (see > #1). One can also make up address, and even signature, if needed, and I > bet no one would spot it. > > 3. I don't buy argument about requirements of some organizations. Linux > kernel is used in billions of devices and by countless organizations, > and I highly doubt that contributing to Linux requires anything like > singing an agreement or whatever. > > You'd be surprised. > > 4. Even in paid services checking a checkbox is usually sufficient for > accepting any license/ToS. > > 5. My intentions are mostly of pragmatic nature. To make things that I > use (and that can be useful to Pharo users) be in upstream. > > 6. I don't care whether you drink beer, your political views, or your > interpersonal relationships (however story with Benjamin shows that > perhaps everything's not as great as you paint it). These are all > irrelevant to Pharo development, from my point of view at least. > > 7. If you don't agree with my arguments and stick to your rules, go for > it. I'm in no position to tell you what's the right thing to do. I'll > just end this discussion and leave. > > Farewell then. > > Phil > > > View this message in context: Re: License agreement - are you kidding me? > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Dec. 8, 2015

Re: [Pharo-dev] CollectionValueHolder additions

by stepharo

Hi peter Do you mean instead of having ValueChanged? What would be scenario for ValueRemoved? Stef Le 8/12/15 01:01, Peter Uhnak a Ã©crit : > Hi, > > when (any) ValueHolder changes, a ValueChanged announcement is fired. > > My question: Would it be a good idea to add ValueAdded and ValueRemoved > for CollectionValueHolder? > > Otherwise there's no way to meaningfully observe changes. >

Dec. 8, 2015

[pharo-project/pharo-core] b01122: 50490

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: b01122f7148d3f9abdb0bb6ae4f2475650701927 https://github.com/pharo-project/pharo-core/commit/b01122f7148d3f9abdb0bb6a… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2015-12-08 (Tue, 08 Dec 2015) Changed paths: M ConfigurationOfFastTable.package/ConfigurationOfFastTable.class/instance/symbolic versions/stable_.st A ConfigurationOfFastTable.package/ConfigurationOfFastTable.class/instance/versions/version081_.st M Morphic-Widgets-FastTable.package/FTAllItemsStrategy.class/instance/action/matchingFilter_.st M Morphic-Widgets-FastTable.package/FTAllItemsStrategy.class/instance/action/searchIn_.st M Morphic-Widgets-FastTable.package/FTAllItemsStrategy.class/instance/action/unexpandAllChildOf_.st M Morphic-Widgets-FastTable.package/FTAnnouncement.class/definition.st A Morphic-Widgets-FastTable.package/FTAnnouncement.class/instance/accessing/fastTable.st A Morphic-Widgets-FastTable.package/FTAnnouncement.class/instance/accessing/fastTable_.st M Morphic-Widgets-FastTable.package/FTBasicItem.class/README.md M Morphic-Widgets-FastTable.package/FTBasicItem.class/definition.st R Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/accessing/expand.st R Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/accessing/expandAndRefresh.st A Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/accessing/recentlyChanged.st R Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/accessing/unexpand.st R Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/accessing/unexpandAndRefresh.st A Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/button/collpasedButton.st M Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/button/expandedButton.st M Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/button/generateButton.st R Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/button/unexpandedButton.st A Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/expanding-collapsing/collapse.st A Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/expanding-collapsing/collapseAll.st A Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/expanding-collapsing/collapseAndRefresh.st A Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/expanding-collapsing/expand.st A Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/expanding-collapsing/expandAndRefresh.st M Morphic-Widgets-FastTable.package/FTBasicItem.class/instance/initialization/initialize.st M Morphic-Widgets-FastTable.package/FTCellMorph.class/README.md M Morphic-Widgets-FastTable.package/FTCellMorph.class/instance/drawing/drawOn_.st A Morphic-Widgets-FastTable.package/FTCellMorph.class/instance/drawing/seperatorColor.st M Morphic-Widgets-FastTable.package/FTColumn.class/README.md M Morphic-Widgets-FastTable.package/FTDataSource.class/README.md M Morphic-Widgets-FastTable.package/FTDataSource.class/instance/accessing/cellColumn_row_.st M Morphic-Widgets-FastTable.package/FTDataSource.class/instance/accessing/elementAt_.st M Morphic-Widgets-FastTable.package/FTDataSource.class/instance/accessing/headerColumn_.st M Morphic-Widgets-FastTable.package/FTDataSource.class/instance/accessing/menuColumn_row_.st M Morphic-Widgets-FastTable.package/FTDataSource.class/instance/accessing/newDataSourceMatching_.st M Morphic-Widgets-FastTable.package/FTDataSource.class/instance/accessing/numberOfRows.st M Morphic-Widgets-FastTable.package/FTDataSource.class/instance/accessing/table.st M Morphic-Widgets-FastTable.package/FTDataSource.class/instance/private/readyToBeDisplayed.st A Morphic-Widgets-FastTable.package/FTExamples.class/class/examples/exampleDragAndDrop4.st M Morphic-Widgets-FastTable.package/FTExamples.class/class/tree examples/exampleTree1.st M Morphic-Widgets-FastTable.package/FTExamples.class/class/tree examples/exampleTreeWithAllItemsFilter.st M Morphic-Widgets-FastTable.package/FTExamples.class/class/tree examples/exampleTreeWithAllItemsSearch.st M Morphic-Widgets-FastTable.package/FTExamples.class/class/tree examples/exampleexampleOneSubLevelTree.st M Morphic-Widgets-FastTable.package/FTFilterFunction.class/instance/updating/filter.st M Morphic-Widgets-FastTable.package/FTOutlineDataSource.class/instance/accessing/cellColumn_row_.st M Morphic-Widgets-FastTable.package/FTOutlineDataSource.class/instance/accessing/elementAt_.st M Morphic-Widgets-FastTable.package/FTOutlineDataSource.class/instance/testing/needSeparatorBefore_.st A Morphic-Widgets-FastTable.package/FTRootItem.class/instance/accessing/recentlyChanged.st A Morphic-Widgets-FastTable.package/FTRootItem.class/instance/expanding-collapsing/collapseAll.st M Morphic-Widgets-FastTable.package/FTSelectionChanged.class/README.md M Morphic-Widgets-FastTable.package/FTStrongSelectionChanged.class/README.md M Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/README.md M Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/drawing/drawOn_.st M Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/private/calculateExactVisibleRows.st M Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/private/calculateStartIndexWhenShowing_.st M Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/private/calculateVisibleRows.st M Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/private/exposedRows.st M Morphic-Widgets-FastTable.package/FTTableContainerMorph.class/instance/testing/canRefreshValues.st R Morphic-Widgets-FastTable.package/FTTableMorph.class/class/as yet unclassified/with_.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/definition.st R Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/accessing colors/backgroundColor.st R Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/accessing colors/backgroundColor_.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/accessing selection/selectRowIndexes_.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/accessing/dataSource_.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/drag and drop/startDrag_.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/event handling/handleMouseMove_.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/event handling/mouseDown_.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/event handling/mouseEnterDragging_.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/event handling/mouseLeaveDragging_.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/event handling/mouseMove_.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/event handling/mouseUp_.st A Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/initialization/defaultColor.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/initialization/initialize.st A Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/updating/autoScrollHeightLimit.st M Morphic-Widgets-FastTable.package/FTTableMorph.class/instance/updating/themeChanged.st A Morphic-Widgets-FastTable.package/FTTableRowMorph.class/instance/event handling/handlesMouseOver_.st A Morphic-Widgets-FastTable.package/FTTableRowMorph.class/instance/event handling/mouseEnter_.st A Morphic-Widgets-FastTable.package/FTTableRowMorph.class/instance/event handling/mouseLeave_.st A Morphic-Widgets-FastTable.package/FTTableRowMorph.class/instance/initialize/mouseOverColor.st M Morphic-Widgets-FastTable.package/FTTableSelectionMorph.class/instance/initialization/initializeTable_row_primary_.st A Morphic-Widgets-FastTable.package/FTTreeDataSource.class/instance/accessing/menuColumn_row_.st A Morphic-Widgets-FastTable.package/FTTreeDataSource.class/instance/expanding-collapsing/collapseAll.st A Morphic-Widgets-FastTable.package/FTTreeDataSource.class/instance/updating/indexOfChangedItem.st A Morphic-Widgets-FastTable.package/FTTreeDataSource.class/instance/updating/updateSelectionWithCollectBlock_.st M Morphic-Widgets-FastTable.package/FTTreeItem.class/instance/accessing/childAt_.st A Morphic-Widgets-FastTable.package/FTTreeItem.class/instance/accessing/recentlyChanged.st A Morphic-Widgets-FastTable.package/FTTreeItem.class/instance/expanding-collapsing/collapseAll.st A Morphic-Widgets-FastTable.package/FTTreeItem.class/instance/updating/selectedRowsIndexesFrom_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50489.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50490.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50489.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50490.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 50490 17211 FastTable update (see description) https://pharo.fogbugz.com/f/cases/17211 http://files.pharo.org/image/50/50490.zip

Dec. 8, 2015

[pharo-project/pharo-core]

by GitHub

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

Dec. 8, 2015

Re: [Pharo-dev] displayingProgress on demand

by stepharo

Could we have a synthesis of the discussion? It would be good to have a list of working solutions with pointers. Stef

Dec. 8, 2015

Re: [Pharo-dev] displayingProgress on demand

by stepharo

I would like to see this code injector too. Stef Le 7/12/15 18:43, Thierry Goubier a Ã©crit : > Hi HernÃ¡n, > > Le 07/12/2015 18:16, HernÃ¡n Morales Durand a Ã©crit : >> Hi Sven >> >> 2015-12-06 17:34 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu >> <mailto:sven@stfx.eu>>: >> >> There is still #do:displayingProgress: >> >> There is Job. >> >> In general, the collection API should not be concerned with GUI >> matters, does it ? >> >> >> Believe me when you're executing a large workflow processing 50Gb files >> with 5 other people expecting feedback from the screen, the least of >> your concerns is the purity of collection API. I don't know what other >> coders do, kick your co-workers off the room? Sit to see a blank Pharo >> screen? >> To me the key is to have feedback from the system without having to >> change your 20 iterators in a group of client classes where you NEED to >> see progress. >> >> Anyway I agree with you Collection should not have GUI dependencies, >> that's the reason I took a different approach and that's why I asked >> with an expression like: >> >> SmalltalkImage setDisplayProgressTo: MyClass. >> >> with such kind of expression you never touch the Collection API. You >> just walk MyClass for every enumeration messsage send (of your interest) >> and perform a transformation. Note the same "technique" could be applied >> for logging and/or profiling. > > Yes. The Jejak tracer uses a similar technique. I'd guess others do as > well. > >> We can't have equivalents of all collection methods for displaying >> progress, nor can it be a (semi-) global setting. >> >> >> Sure, that would be the anti-object technology :) >> >> So I implemented a prototype which injects JobProgress code in methods >> using RBParseSearchTree. On uninstall I plan to recover the previous >> version of marked methods. No need to touch the Collection API at all, >> nor a setting. I am sure the same could be done with MethodWrappers but >> RB can manipulate AST nodes. >> >> However if there is a better idea I would love to hear about it. > > Could you put your RBParseTreeRewriter scripts somewhere? I'm interested. > > Technically, you used one of the best solutions out there to reach > your goal. Now, some would suggest aspect-oriented programming, but, > for me, this is a limited, easier to use API over a rewrite engine > like RB or the Metalinks of Marcus. > > Regards, > > Thierry > > >

Dec. 8, 2015

Re: [Pharo-dev] License agreement - are you kidding me?

by Dimitris Chloupis

The one thing I dont like about that agreement is that it forces to retreat from the personal copyright if I remember the document correctly. Even though personally I would not mind that for bug fixes and small enhancements where my copyright would not be so much of a big deal. For bigger tools and code that I have put substantial effort and suffered pain to make them work I would not give away my copyright. So I am not seeing myself signing this any time soon either. Revealing my real name and some other stuff is not a problem. So I can certainly understand some of your frustration webwarrior. On Tue, Dec 8, 2015 at 10:44 AM phil(a)highoctane.be <phil(a)highoctane.be> wrote: > On Tue, Dec 8, 2015 at 12:47 AM, webwarrior <reg(a)webwarrior.ws> wrote: > >> Considering that there are a couple of responses and the fact that you >> guys are so easily offended, I will not answer everyone but just state >> couple of theses. >> >> >> 0. I will not reveal my real name, because I value privacy. Nickname is >> sufficient for identification purposes. Any other information (real >> name, address, etc.) is not needed for actually contributing code. Think >> of principle of least privilege. >> >> 1. I could easily make up some human-looking name (Satoshi Nakamoto >> anyone?), but will not do it out of principle (see #0). >> >> 2. Knowing contributor's "real" name would not guard you against any >> possible malicious actions from him, because it can't be verified (see >> #1). One can also make up address, and even signature, if needed, and I >> bet no one would spot it. >> >> 3. I don't buy argument about requirements of some organizations. Linux >> kernel is used in billions of devices and by countless organizations, >> and I highly doubt that contributing to Linux requires anything like >> singing an agreement or whatever. >> > > You'd be surprised. > >> >> 4. Even in paid services checking a checkbox is usually sufficient for >> accepting any license/ToS. > > >> 5. My intentions are mostly of pragmatic nature. To make things that I >> use (and that can be useful to Pharo users) be in upstream. >> >> 6. I don't care whether you drink beer, your political views, or your >> interpersonal relationships (however story with Benjamin shows that >> perhaps everything's not as great as you paint it). These are all >> irrelevant to Pharo development, from my point of view at least. >> >> 7. If you don't agree with my arguments and stick to your rules, go for >> it. I'm in no position to tell you what's the right thing to do. I'll >> just end this discussion and leave. >> > > Farewell then. > > Phil > > >> >> ------------------------------ >> View this message in context: Re: License agreement - are you kidding me? >> <http://forum.world.st/License-agreement-are-you-kidding-me-tp4865853p486591…> >> Sent from the Pharo Smalltalk Developers mailing list archive >> <http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html> at >> Nabble.com. >> >

Dec. 8, 2015

Re: [Pharo-dev] displayingProgress on demand

by Sven Van Caekenberghe

If this would work, that would make many people happy ! It would be basically make tracking progress a no-cost option. > On 08 Dec 2015, at 10:29, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2015-12-08 10:16 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Wishfull thinking: > > you have a tradeoff when you do that, you interrupt running code and so changes timings and synchronisations, your scan takes time, and things below your sampling frequency are not visible. > > That being said, and if you take those factors into account, then your approach is sound. Just don't say it is a miracle solution. > > Yes, of course. I mean that such approach should not has so big impact on performance as direct announcing inside loop. Most time it will spend on updating/drawing progress bar. And it is not comparable to time which required to scan call chain. In most cases call chain has very small deep. And retrieving information about progress looks like trivial operation. Besides this analysing happens only when track process wake up. So It gives seconds to run code without interruption. > > I will try find code. But it was not ready to use solution. Just very little experiment for my UI framework Presenty. >

Dec. 8, 2015

Re: [Pharo-dev] displayingProgress on demand

by Thierry Goubier

2015-12-08 10:29 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2015-12-08 10:16 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> Wishfull thinking: >> >> you have a tradeoff when you do that, you interrupt running code and so >> changes timings and synchronisations, your scan takes time, and things >> below your sampling frequency are not visible. >> >> That being said, and if you take those factors into account, then your >> approach is sound. Just don't say it is a miracle solution. >> > > Yes, of course. I mean that such approach should not has so big impact on > performance as direct announcing inside loop. Most time it will spend on > updating/drawing progress bar. And it is not comparable to time which > required to scan call chain. In most cases call chain has very small deep. > And retrieving information about progress looks like trivial operation. > Besides this analysing happens only when track process wake up. So It gives > seconds to run code without interruption. > Hum you give interesting insights into it, like that the call chain isn't very deep. Good to know :) > > I will try find code. But it was not ready to use solution. Just very > little experiment for my UI framework Presenty. > It could be very nice to have for many long-running computations. I think the models used by Serge in SciSmalltalk / Kendrick? could benefit a lot from that. Thierry

Dec. 8, 2015

Re: [Pharo-dev] displayingProgress on demand

by Denis Kudriashov

2015-12-08 10:16 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Wishfull thinking: > > you have a tradeoff when you do that, you interrupt running code and so > changes timings and synchronisations, your scan takes time, and things > below your sampling frequency are not visible. > > That being said, and if you take those factors into account, then your > approach is sound. Just don't say it is a miracle solution. > Yes, of course. I mean that such approach should not has so big impact on performance as direct announcing inside loop. Most time it will spend on updating/drawing progress bar. And it is not comparable to time which required to scan call chain. In most cases call chain has very small deep. And retrieving information about progress looks like trivial operation. Besides this analysing happens only when track process wake up. So It gives seconds to run code without interruption. I will try find code. But it was not ready to use solution. Just very little experiment for my UI framework Presenty.

Dec. 8, 2015