Re: [Pharo-dev] [ANN] Pointer Detective
Very nice.
Now, I am wondering why some instances are where they are in my image :-)
Thx for making this.
Phil
On Wed, Sep 3, 2014 at 4:14 AM, Ben Coman b...@openinworld.com wrote:
Mariano Martinez Peck wrote:
Also, would be nice to filter out StrongPointerExplorerWrapper instances.
I disagree with that being hard coded. Either StrongPointerExplorerWrapper
weakly wraps the object it points to, and so is already handled, or it is a
candidate for preventing object garbage collection. For example, if a UI
element using StrongPointerExplorerWrapper is removed from visibility but
fails to be fully deleted.
What might be good though is provision of a generic filtering mechanism.
Pass the candidate from-object to a user supplied block which returns a
boolean.
cheers -ben
On Tue, Sep 2, 2014 at 5:09 PM, Mariano Martinez Peck
marianop...@gmail.com wrote:
BTW , +1 to the ability of open an inspect on a node.
On Tue, Sep 2, 2014 at 5:05 PM, Mariano Martinez Peck
marianop...@gmail.com wrote:
Hi Ben,
Very nice tool! Thank you very much for it.
Questiondo you think it is possible to add a feature that it
automatically builds the whole graph starting at target object until the GC
root that is holding it? In Pharo, the GC root is the special object array
(see #newSpecialObjectsArray).
So the code should basically do a loop for #pointersTo and check if one
of those pointers is directly one of the array. Or something like that
like.
Probably it will crash the VM hahaha. But it would be nice to track from
a certain object up to the GC root and see all that path in graph :)
On Tue, Sep 2, 2014 at 4:41 PM, Yuriy Tymchuk yuriy.tymc...@me.com
wrote:
Oh yes, this is essential part of “working with objects”. No?
On 02 Sep 2014, at 21:37, Max Leske maxle...@gmail.com wrote:
You are my hero! I was just complaining about that to Doru at ESUG.
This sort of tool should be part of the standard tool set so please keep on
improving it and we’ll try to convince someone to integrate it :)
Max
On 02.09.2014, at 19:40, Ben Coman b...@openinworld.com
b...@openinworld.com wrote:
greetings all,
I had an itch to scratch... I find it difficult using the tree list
of the standard Pointer Explorer to track down why objects aren't garbage
collected. I always fear I'm not going to notice getting caught in a
reference loop. So I created a tool presenting an alternative view as a
directed graph. The graph incrementally builds out from the target object
as you explore it. Nodes are colourised to help manage complexity.
The attached snapshot is produced from evaluating the following
Workspace script...
testObject := 'END5'.
ref1 := { testObject. nil }.
ref2 := { ref1 }.
ref3 := PDTestResource new heldObject: ref2.
ref1 at: 2 put: ref3. note the reference loop this creates
PointerDetective openOn: testObject.
Now I expect I'm duplicating something done before, but I couldn't
find anything quickly and it was an opportunity for some goal direct
learning of Morphic. Thanks to Roassal an option for a spring-force layout
is provided. That code was copied rather than create a dependency, and
might need to be rationalized later.
The code is a bit rough from hacking around learning how to make
things work, but its functional, so its time to get it out in the open.
For more information please refer to the repository home page...
http://smalltalkhub.com/#!/~BenComan/PointerDetective
cheers -ben
PointerDetectiveExample1.png
--
Mariano
http://marianopeck.wordpress.com
--
Mariano
http://marianopeck.wordpress.com
--
Mariano
http://marianopeck.wordpress.com
[Pharo-dev] [Off Topic] PHARO - Already Dead - YouTube
We should sue this guy ;-) https://www.youtube.com/watch?v=S3uktGJVebE
Re: [Pharo-dev] nil pointersTo size
Arrays with empty slots, all collections whose size is smaller than their capacity... :) On Wed, Sep 3, 2014 at 7:52 AM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: All ‘uninitialised’ variables are pointing to nil. I think this is the case Uko On 03 Sep 2014, at 06:10, Ben Coman b...@openinworld.com wrote: I am curious... what does it mean that nil PointersTo size is a large number? Intuitively I'd have thought the answer would be zero. Pharo build 40196 -- ~101,000 Pharo build 30856 -- ~103,000 Pharo build 20628 -- ~80,000 Squeak 4.5 -- ~40,000 cheers -ben
Re: [Pharo-dev] Spec license
The Spec news page [1] explains the license change and anyone can easily guess that it is caused by Benjamins personal disagreements with Stef. No judgement on that from my side as this is a personal issue between the two and as I like most of us have only a few infos on that from the outside. It is interesting that there is also a new Spec release [2] announced this week although in his last post [3] Benjamin stated I am quiting the Pharo community, as well as the Smalltalk community. To me it looks like Benjamin want's to punish Stef - but it will affect the community and the idea WE ALL hardly work on ... Sorry but this is a more childish like reaction from his side and not a good way to solve disagreements. I can only talk about this from an outside point of view but I think nobody in our community will profit from Benjamin reaction - it makes it harder for the whole Pharo community to work with Spec and in my opinion it will be not good for Spec framework or Benjamin either. From what I see now my personal recommendation would be decide within the community if Spec could be a base for the future of our UI and tool building and if so rename and continue in a forked way with the MIT licensed code within the Pharo image so it will not be confused with Benjamins version, license and page. Looks like currently that this is the only way to continue with it and ensure contributions will stay single licensed/MIT licensed. We can only change the future - not the past... Thx T. [1] http://spec.st/license/gpl/mit/2014/08/15/Spec_change_license.html [2] http://spec.st/news/#Spec%202.0.0%20release [3] http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2014-August/099354.html
Re: [Pharo-dev] Rewrite rules doc?
look in the notes folder inside the ParseTreeRewriter chapter on github. Normally I collected all the information I could find and this is why we will continue to write and finish this chapter with mark. st On 2/9/14 14:18, Yuriy Tymchuk wrote: Hi guys. Is there any doc about rewrite rules besides https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSuccessfulBuild/artifact/RewriteTool/RewriteTool.pier.pdf ? Uko
Re: [Pharo-dev] Proportional Tab Stops
Hi, Glad to hear from you. Thanks for spotting the issue with tabbing. I think your suggestion of having tabs spacing being proportional with the font size makes sense. Could we interest you in submitting a slice for this? :) Cheers, Doru On Wed, Sep 3, 2014 at 9:43 AM, J.F. Rick s...@je77.com wrote: Hi everyone, I'm writing for two reasons. First, I wanted to let people know that I haven't disappeared. I'm just having to take a break as I finish up with my current academic post. As I am no longer going to be there, Pharo contributions don't help the department. So, I can't justify devoting any time to Pharo. But, I'm still interested in Athens, multitouch support, and Pharo for beginners. In October, I move back to Atlanta and will start a company. At that point, I aim to be back, though I may concentrate a bit more on server technology (full version of newest QRCode specifications half way done). Second, I wanted to mention a slight annoyance and suggest a solution. Background: I taught a class on introduction / intermediate programming in Pharo the last few years. One thing I try to teach my students is to use proper indention for their code. Unlike Python (great syntax for a first language), you do not need to indent in Smalltalk for code to work properly so students don't have to properly use indention to organize their code. For tiny bits of code (as is required in introductory programming), indention is not that important but it gets more important as they advance. Even my better students often used bad indention practices, though I emphasized it in class and all sample code I gave them was properly indented. In class, I often solved problems and demonstrated code. So that students could see what I typed, I increased the size of the font (24pt standard font). Though the font increased, the tab spacing remained the same. So, when I indented with one tab, it looked much smaller than a tab would have looked on their 10pt code editor. I saw people using spaces to indent code, which I never talked about. My guess is that they were trying to replicate the amount of space that my code was indented. They saw that a tab looked too big and used spaces. A simple solution is for tab spacing in code panes to increase proportionally with the font size. I feel like suggesting that as an improvement for Pharo 4. Does that seem reasonable? Are there arguments against it? Cheers, Jeff -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] [Off Topic] PHARO - Already Dead - YouTube
Yes I saw it too :) On 3/9/14 09:40, Sven Van Caekenberghe wrote: We should sue this guy ;-) https://www.youtube.com/watch?v=S3uktGJVebE
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/40197 Home: https://github.com/pharo-project/pharo-core
[Pharo-dev] [pharo-project/pharo-core] f3cc5d: 40197
Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: f3cc5d2f04f303f3132b6d095b7a656e1f7e9754 https://github.com/pharo-project/pharo-core/commit/f3cc5d2f04f303f3132b6d095b7a656e1f7e9754 Author: Jenkins Build Server bo...@pharo-project.org Date: 2014-09-03 (Wed, 03 Sep 2014) Changed paths: M OpalCompiler-Core.package/extension/TClass/instance/classSideCompiler.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script197.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40197.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: --- 40197 13938 Opal, custom compilers and class side methods https://pharo.fogbugz.com/f/cases/13938 http://files.pharo.org/image/40/40197.zip
Re: [Pharo-dev] [Off Topic] PHARO - Already Dead - YouTube
Man, are you sure that you want to advertise publicly that you are listening to this music? :)) Doru On Wed, Sep 3, 2014 at 11:00 AM, stepharo steph...@free.fr wrote: Yes I saw it too :) On 3/9/14 09:40, Sven Van Caekenberghe wrote: We should sue this guy ;-) https://www.youtube.com/watch?v=S3uktGJVebE -- www.tudorgirba.com Every thing has its own flow
[Pharo-dev] Undeclared dictionary
Hi, can someone explain me how Undeclared dictionary works? Because as I look at it, all the values are nil. Is it possible for them to be not nil? Maybe we should have a “global variable comments” for this situations :) Uko
[Pharo-dev] OrderedCollection protocols are broken: a potential fix
Hello guys, I was looking into the OrderedCollection protocols recently to see how well the sista optimizer perform with it methods, and I realized that this is completely broken. For example: col := #(1 2 3 4 5) asOrderedCollection. col do: [ :elem | elem trace . elem 4 ifTrue: [ col add: col size + 1 ]]. = '12345678' However: col := #(1 2 3 4 5) asOrderedCollection. col collect: [ :elem | elem trace . elem 4 ifTrue: [ col add: col size + 1 ]]. = '12345' This means that #do: and #reverseDo: iterate over all the elements of the collection,*including* the ones that you are adding while iterating over the collection, whereas all the other OrderedCollection protocols, such as #collect:, #select:, iterates over all the elements of the collection, *excluding* the ones you are adding while iterating over the collection. Marcus argued that one should not edit a collection while iterating over it, however this point is not valid as the World menu relies on this feature, using #do: to iterate over the elements of the OrderedCollection including the one it is adding while iterating over the collection. Changing the implementation makes the world menu display half of its items. I don't like this difference because it is inconsistent. For example, refactoring a #do: into a #collect: can simply not work because they do not iterate over the same elements if you are editing the collection while iterating over it. In VW, the protocols are consistent and iterating over a collection never iterates over the elements one is adding while iterating over it. Therefore, I believe most frameworks should expect this behavior (at least the ones cross smalltalk) which sounds the most correct. I think we should fix the world menu implementation and make the protocols consistent. Alternatively, we can let VW be a much more consistent Smalltalk environment than Pharo. What do you think ? Clement
Re: [Pharo-dev] [Off Topic] PHARO - Already Dead - YouTube
Yeah, I admit it, I am addicted to Pharo ;-) A compulsive need to use Pharo in order to function normally. When the use of Pharo is unobtainable, the user suffers from withdrawal. On 03 Sep 2014, at 11:14, Tudor Girba tu...@tudorgirba.com wrote: Man, are you sure that you want to advertise publicly that you are listening to this music? :)) Doru On Wed, Sep 3, 2014 at 11:00 AM, stepharo steph...@free.fr wrote: Yes I saw it too :) On 3/9/14 09:40, Sven Van Caekenberghe wrote: We should sue this guy ;-) https://www.youtube.com/watch?v=S3uktGJVebE -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] Proportional Tab Stops
Tudor Girba wrote: Hi, Glad to hear from you. Thanks for spotting the issue with tabbing. I think your suggestion of having tabs spacing being proportional with the font size makes sense. Could we interest you in submitting a slice for this? :) Cheers, Doru I think he indicated he did not have time right now :) Rick, I think that sounds like a good idea. Maybe you could log a ticket on Fogbugz, so you can... * stay updated with any action on it * be involved in testing any proposed solutions * when you back into the Pharo groove, if its still an outstanding issue you might have a shot at it yourself. cheers -ben On Wed, Sep 3, 2014 at 9:43 AM, J.F. Rick s...@je77.com wrote: Hi everyone, I'm writing for two reasons. First, I wanted to let people know that I haven't disappeared. I'm just having to take a break as I finish up with my current academic post. As I am no longer going to be there, Pharo contributions don't help the department. So, I can't justify devoting any time to Pharo. But, I'm still interested in Athens, multitouch support, and Pharo for beginners. In October, I move back to Atlanta and will start a company. At that point, I aim to be back, though I may concentrate a bit more on server technology (full version of newest QRCode specifications half way done). Second, I wanted to mention a slight annoyance and suggest a solution. Background: I taught a class on introduction / intermediate programming in Pharo the last few years. One thing I try to teach my students is to use proper indention for their code. Unlike Python (great syntax for a first language), you do not need to indent in Smalltalk for code to work properly so students don't have to properly use indention to organize their code. For tiny bits of code (as is required in introductory programming), indention is not that important but it gets more important as they advance. Even my better students often used bad indention practices, though I emphasized it in class and all sample code I gave them was properly indented. In class, I often solved problems and demonstrated code. So that students could see what I typed, I increased the size of the font (24pt standard font). Though the font increased, the tab spacing remained the same. So, when I indented with one tab, it looked much smaller than a tab would have looked on their 10pt code editor. I saw people using spaces to indent code, which I never talked about. My guess is that they were trying to replicate the amount of space that my code was indented. They saw that a tab looked too big and used spaces. A simple solution is for tab spacing in code panes to increase proportionally with the font size. I feel like suggesting that as an improvement for Pharo 4. Does that seem reasonable? Are there arguments against it? Cheers, Jeff -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick -- www.tudorgirba.com "Every thing has its own flow"
Re: [Pharo-dev] Undeclared dictionary
On Wed, Sep 3, 2014 at 11:24 AM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi, can someone explain me how Undeclared dictionary works? So imagine you want to load code where a variable is not defined (e.g. due to loading old code, or because it references a variable that will only be loaded in a second step). In interactive mode, the compiler tells you. But in non-interactive mode (file in, mc load), it just loads the wrong code and for every undeclared variable, it adds an entry in the Undeclared dictionary. (the bytecode to read and write is the same as used for Globals and Class variables: pushLiteralVariable, which means push the value of the association, the store bytecode for assignment therefore is store in the value of that association. So if you actually run code that has Undeclared, it will work: it will be nil by default, but when you assign it will store into the Undeclared dictionary. When you add a new Global to the SystemDictionary, it will check Undeclared and move the value over. Same for Class vars. (this means that loading a class will automatically fix all Undeclared references to it) Because as I look at it, all the values are nil. Is it possible for them to be not nil? yes. Maybe we should have a “global variable comments” for this situations :) Ideed. -- Marcus Denker -- den...@acm.org http://www.marcusdenker.de
Re: [Pharo-dev] OrderedCollection protocols are broken: a potential fix
Clement, I am not sure, but could this not be a compiler issue ? Not with Opal but with the old compiler ?! I mean, if you look at the implementations of OrderedCollection#do: and OrderedCollection#collect: they basically do the same thing, going from firstIndex to lastIndex, both of which are instance variables, but in the first case, the #do:, the end test is evaluated on each iteration, while in the second case, the #to:do:, the end test should be evaluated only once. Since lastIndex changes while iterating, one iteration sees it, the other not. Looking at the byte codes seems to confirm that: the compilation of the #:to:do is different: Opal correctly moves both instance variables to temps, while the old compiler keeps on referring to the second instance variable (lastIndex) directly on each loop - which is plain wrong IMHO. I am with Marcus that you should not modify a collection that you iterate over. What if you would be inserting values at arbitrary places ? I am with you that both (all) enumerations should be consistent. Like in VW, delegating to the simplest #do: seems best. Sven On 03 Sep 2014, at 11:42, Clément Bera bera.clem...@gmail.com wrote: Hello guys, I was looking into the OrderedCollection protocols recently to see how well the sista optimizer perform with it methods, and I realized that this is completely broken. For example: col := #(1 2 3 4 5) asOrderedCollection. col do: [ :elem | elem trace . elem 4 ifTrue: [ col add: col size + 1 ]]. = '12345678' However: col := #(1 2 3 4 5) asOrderedCollection. col collect: [ :elem | elem trace . elem 4 ifTrue: [ col add: col size + 1 ]]. = '12345' This means that #do: and #reverseDo: iterate over all the elements of the collection,*including* the ones that you are adding while iterating over the collection, whereas all the other OrderedCollection protocols, such as #collect:, #select:, iterates over all the elements of the collection, *excluding* the ones you are adding while iterating over the collection. Marcus argued that one should not edit a collection while iterating over it, however this point is not valid as the World menu relies on this feature, using #do: to iterate over the elements of the OrderedCollection including the one it is adding while iterating over the collection. Changing the implementation makes the world menu display half of its items. I don't like this difference because it is inconsistent. For example, refactoring a #do: into a #collect: can simply not work because they do not iterate over the same elements if you are editing the collection while iterating over it. In VW, the protocols are consistent and iterating over a collection never iterates over the elements one is adding while iterating over it. Therefore, I believe most frameworks should expect this behavior (at least the ones cross smalltalk) which sounds the most correct. I think we should fix the world menu implementation and make the protocols consistent. Alternatively, we can let VW be a much more consistent Smalltalk environment than Pharo. What do you think ? Clement
Re: [Pharo-dev] OrderedCollection protocols are broken: a potential fix
On Wed, 3 Sep 2014, Clément Bera wrote: Hello guys, I was looking into the OrderedCollection protocols recently to see how well the sista optimizer perform with it methods, and I realized that this is completely broken. For example: col := #(1 2 3 4 5) asOrderedCollection. col do: [ :elem | elem trace . elem 4 ifTrue: [ col add: col size + 1 ]]. = '12345678' However: col := #(1 2 3 4 5) asOrderedCollection. col collect: [ :elem | elem trace . elem 4 ifTrue: [ col add: col size + 1 ]]. = '12345' This means that #do: and #reverseDo: iterate over all the elements of the collection,*including* the ones that you are adding while iterating over the collection, whereas all the other OrderedCollection protocols, such as #collect:, #select:, iterates over all the elements of the collection, *excluding* the ones you are adding while iterating over the collection. In case of #select and #collect: this is only true for elements added with #addLast:, #addFirst:, or #add:, but there are other methods which can have (even worse) side effects (#add:after:, #add:before:, etc). Levente Marcus argued that one should not edit a collection while iterating over it, however this point is not valid as the World menu relies on this feature, using #do: to iterate over the elements of the OrderedCollection including the one it is adding while iterating over the collection. Changing the implementation makes the world menu display half of its items. I don't like this difference because it is inconsistent. For example, refactoring a #do: into a #collect: can simply not work because they do not iterate over the same elements if you are editing the collection while iterating over it. In VW, the protocols are consistent and iterating over a collection never iterates over the elements one is adding while iterating over it. Therefore, I believe most frameworks should expect this behavior (at least the ones cross smalltalk) which sounds the most correct. I think we should fix the world menu implementation and make the protocols consistent. Alternatively, we can let VW be a much more consistent Smalltalk environment than Pharo. What do you think ? Clement
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/40198 Home: https://github.com/pharo-project/pharo-core
[Pharo-dev] [pharo-project/pharo-core] dd8739: 40198
Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: dd8739108d56ca8cfd1ee003ca846101eab522c9 https://github.com/pharo-project/pharo-core/commit/dd8739108d56ca8cfd1ee003ca846101eab522c9 Author: Jenkins Build Server bo...@pharo-project.org Date: 2014-09-03 (Wed, 03 Sep 2014) Changed paths: M AsmJit-x86.package/AJx86InstructionDescription.class/instance/emitting/emitsmnemonic_operand1_operand2_operand3_.st M ProfStef-Core.package/PharoSyntaxTutorial.class/instance/interactive/prepareDebuggerExample.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script198.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40198.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Spec-Debugger.package/EyeDebuggerContextInspector.class/instance/list/generateElements.st Log Message: --- 40198 13942 Deselecting stacklist can throw MNU https://pharo.fogbugz.com/f/cases/13942 13945 Author reset should not be called directly https://pharo.fogbugz.com/f/cases/13945 http://files.pharo.org/image/40/40198.zip
Re: [Pharo-dev] OrderedCollection protocols are broken: a potential fix
On 3 sept. 2014, at 11:42, Clément Bera bera.clem...@gmail.com wrote: Hello guys, I was looking into the OrderedCollection protocols recently to see how well the sista optimizer perform with it methods, and I realized that this is completely broken. For example: col := #(1 2 3 4 5) asOrderedCollection. col do: [ :elem | elem trace . elem 4 ifTrue: [ col add: col size + 1 ]]. = '12345678' However: col := #(1 2 3 4 5) asOrderedCollection. col collect: [ :elem | elem trace . elem 4 ifTrue: [ col add: col size + 1 ]]. = '12345' This means that #do: and #reverseDo: iterate over all the elements of the collection,*including* the ones that you are adding while iterating over the collection, whereas all the other OrderedCollection protocols, such as #collect:, #select:, iterates over all the elements of the collection, *excluding* the ones you are adding while iterating over the collection. Marcus argued that one should not edit a collection while iterating over it, however this point is not valid as the World menu relies on this feature, using #do: to iterate over the elements of the OrderedCollection including the one it is adding while iterating over the collection. Changing the implementation makes the world menu display half of its items. I don't like this difference because it is inconsistent. For example, refactoring a #do: into a #collect: can simply not work because they do not iterate over the same elements if you are editing the collection while iterating over it. In VW, the protocols are consistent and iterating over a collection never iterates over the elements one is adding while iterating over it. Therefore, I believe most frameworks should expect this behavior (at least the ones cross smalltalk) which sounds the most correct. I think we should fix the world menu implementation and make the protocols consistent. Alternatively, we can let VW be a much more consistent Smalltalk environment than Pharo. What do you think ? The thing is to find alternative implementations that are efficient enough (no copy). Maybe we can get some inspirations from VW for that (how do they do BTW?). You should also check with other kinds of collection because they may act differently than OrderedCollection. So in the end it depends on the amount of effort needed to make all collections consistent with this new requirement and on the resulting overhead. If it's too much, I think that following the old advice don't modify a collection while iterating it is enough. If one really needs to do such kind of things he should consider an alternative design like using a zipper for example. Camille Clement
Re: [Pharo-dev] Undeclared dictionary
Thank you Marcus! This is very helpful. Uko On 03 Sep 2014, at 13:47, Marcus Denker marcus.den...@inria.fr wrote: On Wed, Sep 3, 2014 at 11:24 AM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi, can someone explain me how Undeclared dictionary works? So imagine you want to load code where a variable is not defined (e.g. due to loading old code, or because it references a variable that will only be loaded in a second step). In interactive mode, the compiler tells you. But in non-interactive mode (file in, mc load), it just loads the wrong code and for every undeclared variable, it adds an entry in the Undeclared dictionary. (the bytecode to read and write is the same as used for Globals and Class variables: pushLiteralVariable, which means push the value of the association, the store bytecode for assignment therefore is store in the value of that association. So if you actually run code that has Undeclared, it will work: it will be nil by default, but when you assign it will store into the Undeclared dictionary. When you add a new Global to the SystemDictionary, it will check Undeclared and move the value over. Same for Class vars. (this means that loading a class will automatically fix all Undeclared references to it) Because as I look at it, all the values are nil. Is it possible for them to be not nil? yes. Maybe we should have a “global variable comments” for this situations :) Ideed. -- Marcus Denker -- den...@acm.org http://www.marcusdenker.de
[Pharo-dev] speed up with:do: by not checking size
with:do: on SequencableCollection checks that both collections have the same size (it raises an Error if not). with: otherCollection do: twoArgBlock Evaluate twoArgBlock with corresponding elements from this collection and otherCollection. otherCollection size = self size ifFalse: [self error: 'otherCollection must be the same size']. 1 to: self size do: [:index | twoArgBlock value: (self at: index) value: (otherCollection at: index)] I think we should not do that: 1) it is slow 2) when the other is larger, is would work and just omit the rest 3) if it is smaller, you will get an error anyway There are just three methods doing such a size check: with:do: with:collect: reverseWith:do: (the last one actually raises a SizeMismatch exception, it is the sole user of that exception) Is there a reason why this makes sense? I added an issue with a slice to clean it up: https://pharo.fogbugz.com/f/cases/13946/speed-up-with-do-by-not-checking-size Marcus
Re: [Pharo-dev] OrderedCollection protocols are broken: a potential fix
On 3 September 2014 11:42, Clément Bera bera.clem...@gmail.com wrote: Hello guys, I was looking into the OrderedCollection protocols recently to see how well the sista optimizer perform with it methods, and I realized that this is completely broken. For example: col := #(1 2 3 4 5) asOrderedCollection. col do: [ :elem | elem trace . elem 4 ifTrue: [ col add: col size + 1 ]]. = '12345678' However: col := #(1 2 3 4 5) asOrderedCollection. col collect: [ :elem | elem trace . elem 4 ifTrue: [ col add: col size + 1 ]]. = '12345' This means that #do: and #reverseDo: iterate over all the elements of the collection,*including* the ones that you are adding while iterating over the collection, whereas all the other OrderedCollection protocols, such as #collect:, #select:, iterates over all the elements of the collection, *excluding* the ones you are adding while iterating over the collection. Marcus argued that one should not edit a collection while iterating over it, however this point is not valid as the World menu relies on this feature, using #do: to iterate over the elements of the OrderedCollection including the one it is adding while iterating over the collection. Changing the implementation makes the world menu display half of its items. I don't like this difference because it is inconsistent. For example, refactoring a #do: into a #collect: can simply not work because they do not iterate over the same elements if you are editing the collection while iterating over it. An arbitrary rule. The whole world does not defines what to expect from collection when you modifying it during iterating over it.. You can introduce any rule.. but don't expect this won't surprise the users.. because there's no obvious / 'least surprising' behavior can be defined. In VW, the protocols are consistent and iterating over a collection never iterates over the elements one is adding while iterating over it. Therefore, I believe most frameworks should expect this behavior (at least the ones cross smalltalk) which sounds the most correct. I think we should fix the world menu implementation and make the protocols consistent. Alternatively, we can let VW be a much more consistent Smalltalk environment than Pharo. What do you think ? Wrong wrong wrong.. you either iterate over collection, or modify it.. not both. We must fix wrong uses of collections.. not collection. It is all right with collection implementation. You put expectations into a place where should be none: the behavior of iterating over collection while modifying it is *undefined* That's the only rule which should be there. Period. Clement -- Best regards, Igor Stasenko.
Re: [Pharo-dev] OrderedCollection protocols are broken: a potential fix
I think we should change OrderedCollection#do: aBlock Override the superclass for performance reasons. firstIndex to: lastIndex do: [ :index | aBlock value: (array at: index) ] Clement, Do you happen to know exactly where the world menu building goes wrong ? Sven On 03 Sep 2014, at 13:51, Sven Van Caekenberghe s...@stfx.eu wrote: Clement, I am not sure, but could this not be a compiler issue ? Not with Opal but with the old compiler ?! I mean, if you look at the implementations of OrderedCollection#do: and OrderedCollection#collect: they basically do the same thing, going from firstIndex to lastIndex, both of which are instance variables, but in the first case, the #do:, the end test is evaluated on each iteration, while in the second case, the #to:do:, the end test should be evaluated only once. Since lastIndex changes while iterating, one iteration sees it, the other not. Looking at the byte codes seems to confirm that: the compilation of the #:to:do is different: Opal correctly moves both instance variables to temps, while the old compiler keeps on referring to the second instance variable (lastIndex) directly on each loop - which is plain wrong IMHO. I am with Marcus that you should not modify a collection that you iterate over. What if you would be inserting values at arbitrary places ? I am with you that both (all) enumerations should be consistent. Like in VW, delegating to the simplest #do: seems best. Sven On 03 Sep 2014, at 11:42, Clément Bera bera.clem...@gmail.com wrote: Hello guys, I was looking into the OrderedCollection protocols recently to see how well the sista optimizer perform with it methods, and I realized that this is completely broken. For example: col := #(1 2 3 4 5) asOrderedCollection. col do: [ :elem | elem trace . elem 4 ifTrue: [ col add: col size + 1 ]]. = '12345678' However: col := #(1 2 3 4 5) asOrderedCollection. col collect: [ :elem | elem trace . elem 4 ifTrue: [ col add: col size + 1 ]]. = '12345' This means that #do: and #reverseDo: iterate over all the elements of the collection,*including* the ones that you are adding while iterating over the collection, whereas all the other OrderedCollection protocols, such as #collect:, #select:, iterates over all the elements of the collection, *excluding* the ones you are adding while iterating over the collection. Marcus argued that one should not edit a collection while iterating over it, however this point is not valid as the World menu relies on this feature, using #do: to iterate over the elements of the OrderedCollection including the one it is adding while iterating over the collection. Changing the implementation makes the world menu display half of its items. I don't like this difference because it is inconsistent. For example, refactoring a #do: into a #collect: can simply not work because they do not iterate over the same elements if you are editing the collection while iterating over it. In VW, the protocols are consistent and iterating over a collection never iterates over the elements one is adding while iterating over it. Therefore, I believe most frameworks should expect this behavior (at least the ones cross smalltalk) which sounds the most correct. I think we should fix the world menu implementation and make the protocols consistent. Alternatively, we can let VW be a much more consistent Smalltalk environment than Pharo. What do you think ? Clement
Re: [Pharo-dev] OrderedCollection protocols are broken: a potential fix
On 03 Sep 2014, at 14:43, Igor Stasenko siguc...@gmail.com wrote: In VW, the protocols are consistent and iterating over a collection never iterates over the elements one is adding while iterating over it. Therefore, I believe most frameworks should expect this behavior (at least the ones cross smalltalk) which sounds the most correct. I think we should fix the world menu implementation and make the protocols consistent. Alternatively, we can let VW be a much more consistent Smalltalk environment than Pharo. What do you think ? Wrong wrong wrong.. you either iterate over collection, or modify it.. not both. So you actually agree :-) Marcus
Re: [Pharo-dev] OrderedCollection protocols are broken: a potential fix
:) On Wed, Sep 3, 2014 at 2:47 PM, Marcus Denker marcus.den...@inria.fr wrote: On 03 Sep 2014, at 14:43, Igor Stasenko siguc...@gmail.com wrote: In VW, the protocols are consistent and iterating over a collection never iterates over the elements one is adding while iterating over it. Therefore, I believe most frameworks should expect this behavior (at least the ones cross smalltalk) which sounds the most correct. I think we should fix the world menu implementation and make the protocols consistent. Alternatively, we can let VW be a much more consistent Smalltalk environment than Pharo. What do you think ? Wrong wrong wrong.. you either iterate over collection, or modify it.. not both. So you actually agree :-) Marcus -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] [Off Topic] PHARO - Already Dead - YouTube
I'm sure he's building some sort of bot to reach every Pharo mention in web and beyond :D Esteban A. Maringolo 2014-09-03 6:14 GMT-03:00 Tudor Girba tu...@tudorgirba.com: Man, are you sure that you want to advertise publicly that you are listening to this music? :)) Doru On Wed, Sep 3, 2014 at 11:00 AM, stepharo steph...@free.fr wrote: Yes I saw it too :) On 3/9/14 09:40, Sven Van Caekenberghe wrote: We should sue this guy ;-) https://www.youtube.com/watch?v=S3uktGJVebE -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] OrderedCollection protocols are broken: a potential fix
On 3 September 2014 14:47, Marcus Denker marcus.den...@inria.fr wrote: On 03 Sep 2014, at 14:43, Igor Stasenko siguc...@gmail.com wrote: In VW, the protocols are consistent and iterating over a collection never iterates over the elements one is adding while iterating over it. Therefore, I believe most frameworks should expect this behavior (at least the ones cross smalltalk) which sounds the most correct. I think we should fix the world menu implementation and make the protocols consistent. Alternatively, we can let VW be a much more consistent Smalltalk environment than Pharo. What do you think ? Wrong wrong wrong.. you either iterate over collection, or modify it.. not both. So you actually agree :-) I didn't read carefully enough.. but people start the discussion about 'how to fix OrderedColletion' which, as to me, bad signal since it goes wrong way. I am violently against it. You don't 'fix' core classes to make some abuses work. Fix abuses instead. Making abuses work, is opening can of worms, because today you pleased one abuse, tomorrow you will be forced to please another one.. and the finale of it will be complete loss of so beloved consistency. Marcus -- Best regards, Igor Stasenko.
Re: [Pharo-dev] nil pointersTo size
Ah yes. I should have worked that out myself, from here...
ProtoObjectpointsTo:
^ (self instVarsInclude: anObject) or: [ ^self class ==
anObject]
for example
{ nil } pointsTo: nil "-- true"
thanks Yuriy.
cheers -ben
Yuriy Tymchuk wrote:
All ‘uninitialised’ variables are pointing to nil. I think this is the case
Uko
On 03 Sep 2014, at 06:10, Ben Coman b...@openinworld.com wrote:
I am curious... what does it mean that
nil PointersTo size is a large number? Intuitively I'd have thought the answer would be zero.
Pharo build 40196 -- ~101,000
Pharo build 30856 -- ~103,000
Pharo build 20628 -- ~80,000
Squeak 4.5 -- ~40,000
cheers -ben
Re: [Pharo-dev] Proportional Tab Stops
Sure. I'll add a ticket to Fogbugz since nobody has any real objections to my proposed solution. Once I have some time, I might try to solve it myself. Cheers, Jeff On Wed, Sep 3, 2014 at 1:36 PM, Ben Coman b...@openinworld.com wrote: Tudor Girba wrote: Hi, Glad to hear from you. Thanks for spotting the issue with tabbing. I think your suggestion of having tabs spacing being proportional with the font size makes sense. Could we interest you in submitting a slice for this? :) Cheers, Doru I think he indicated he did not have time right now :) Rick, I think that sounds like a good idea. Maybe you could log a ticket on Fogbugz, so you can... * stay updated with any action on it * be involved in testing any proposed solutions * when you back into the Pharo groove, if its still an outstanding issue you might have a shot at it yourself. cheers -ben On Wed, Sep 3, 2014 at 9:43 AM, J.F. Rick s...@je77.com wrote: Hi everyone, I'm writing for two reasons. First, I wanted to let people know that I haven't disappeared. I'm just having to take a break as I finish up with my current academic post. As I am no longer going to be there, Pharo contributions don't help the department. So, I can't justify devoting any time to Pharo. But, I'm still interested in Athens, multitouch support, and Pharo for beginners. In October, I move back to Atlanta and will start a company. At that point, I aim to be back, though I may concentrate a bit more on server technology (full version of newest QRCode specifications half way done). Second, I wanted to mention a slight annoyance and suggest a solution. Background: I taught a class on introduction / intermediate programming in Pharo the last few years. One thing I try to teach my students is to use proper indention for their code. Unlike Python (great syntax for a first language), you do not need to indent in Smalltalk for code to work properly so students don't have to properly use indention to organize their code. For tiny bits of code (as is required in introductory programming), indention is not that important but it gets more important as they advance. Even my better students often used bad indention practices, though I emphasized it in class and all sample code I gave them was properly indented. In class, I often solved problems and demonstrated code. So that students could see what I typed, I increased the size of the font (24pt standard font). Though the font increased, the tab spacing remained the same. So, when I indented with one tab, it looked much smaller than a tab would have looked on their 10pt code editor. I saw people using spaces to indent code, which I never talked about. My guess is that they were trying to replicate the amount of space that my code was indented. They saw that a tab looked too big and used spaces. A simple solution is for tab spacing in code panes to increase proportionally with the font size. I feel like suggesting that as an improvement for Pharo 4. Does that seem reasonable? Are there arguments against it? Cheers, Jeff -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick -- www.tudorgirba.com Every thing has its own flow -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
Re: [Pharo-dev] Proportional Tab Stops
Thanks! Doru On Wed, Sep 3, 2014 at 3:21 PM, J.F. Rick s...@je77.com wrote: Sure. I'll add a ticket to Fogbugz since nobody has any real objections to my proposed solution. Once I have some time, I might try to solve it myself. Cheers, Jeff On Wed, Sep 3, 2014 at 1:36 PM, Ben Coman b...@openinworld.com wrote: Tudor Girba wrote: Hi, Glad to hear from you. Thanks for spotting the issue with tabbing. I think your suggestion of having tabs spacing being proportional with the font size makes sense. Could we interest you in submitting a slice for this? :) Cheers, Doru I think he indicated he did not have time right now :) Rick, I think that sounds like a good idea. Maybe you could log a ticket on Fogbugz, so you can... * stay updated with any action on it * be involved in testing any proposed solutions * when you back into the Pharo groove, if its still an outstanding issue you might have a shot at it yourself. cheers -ben On Wed, Sep 3, 2014 at 9:43 AM, J.F. Rick s...@je77.com wrote: Hi everyone, I'm writing for two reasons. First, I wanted to let people know that I haven't disappeared. I'm just having to take a break as I finish up with my current academic post. As I am no longer going to be there, Pharo contributions don't help the department. So, I can't justify devoting any time to Pharo. But, I'm still interested in Athens, multitouch support, and Pharo for beginners. In October, I move back to Atlanta and will start a company. At that point, I aim to be back, though I may concentrate a bit more on server technology (full version of newest QRCode specifications half way done). Second, I wanted to mention a slight annoyance and suggest a solution. Background: I taught a class on introduction / intermediate programming in Pharo the last few years. One thing I try to teach my students is to use proper indention for their code. Unlike Python (great syntax for a first language), you do not need to indent in Smalltalk for code to work properly so students don't have to properly use indention to organize their code. For tiny bits of code (as is required in introductory programming), indention is not that important but it gets more important as they advance. Even my better students often used bad indention practices, though I emphasized it in class and all sample code I gave them was properly indented. In class, I often solved problems and demonstrated code. So that students could see what I typed, I increased the size of the font (24pt standard font). Though the font increased, the tab spacing remained the same. So, when I indented with one tab, it looked much smaller than a tab would have looked on their 10pt code editor. I saw people using spaces to indent code, which I never talked about. My guess is that they were trying to replicate the amount of space that my code was indented. They saw that a tab looked too big and used spaces. A simple solution is for tab spacing in code panes to increase proportionally with the font size. I feel like suggesting that as an improvement for Pharo 4. Does that seem reasonable? Are there arguments against it? Cheers, Jeff -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick -- www.tudorgirba.com Every thing has its own flow -- Jochen Jeff Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] OrderedCollection protocols are broken: a potential fix
Hello, Sven you are right, the old compiler was consistent in the sense that it always iterated over all the elements, including the ones added with #add: and #addLast: while iterating over the collection. On the other hand, VW is consistent with the Opal implementation for #to:do: in the sense that they iterate only on the elements of the collection excluding the ones added while iterating. #add:after: and co do not work well if you edit the collection while iterating over it for sure :). It's too late for don't modify a collection while iterating it because the system does it, for example, to build the world menu. So I think the solution is in two steps: - removing code which edit the collection while iterating over it. As most frameworks work both on Pharo and VW and that the behavior is different I think there shouldn't be that much, so fixing the Pharo image may be enough. - be consistent in our collection protocol, basically by rewriting do: and reverseDo: like that: FROM: do: aBlock Override the superclass for performance reasons. | index | index := firstIndex. [index = lastIndex] whileTrue: [aBlock value: (array at: index). index := index + 1] TO: do: aBlock Override the superclass for performance reasons. firstIndex to: lastIndex do: [ :index | aBlock value: (array at: index) ] 2014-09-03 14:05 GMT+02:00 Camille Teruel camille.ter...@gmail.com: On 3 sept. 2014, at 11:42, Clément Bera bera.clem...@gmail.com wrote: Hello guys, I was looking into the OrderedCollection protocols recently to see how well the sista optimizer perform with it methods, and I realized that this is completely broken. For example: col := #(1 2 3 4 5) asOrderedCollection. col do: [ :elem | elem trace . elem 4 ifTrue: [ col add: col size + 1 ]]. = '12345678' However: col := #(1 2 3 4 5) asOrderedCollection. col collect: [ :elem | elem trace . elem 4 ifTrue: [ col add: col size + 1 ]]. = '12345' This means that #do: and #reverseDo: iterate over all the elements of the collection,*including* the ones that you are adding while iterating over the collection, whereas all the other OrderedCollection protocols, such as #collect:, #select:, iterates over all the elements of the collection, *excluding* the ones you are adding while iterating over the collection. Marcus argued that one should not edit a collection while iterating over it, however this point is not valid as the World menu relies on this feature, using #do: to iterate over the elements of the OrderedCollection including the one it is adding while iterating over the collection. Changing the implementation makes the world menu display half of its items. I don't like this difference because it is inconsistent. For example, refactoring a #do: into a #collect: can simply not work because they do not iterate over the same elements if you are editing the collection while iterating over it. In VW, the protocols are consistent and iterating over a collection never iterates over the elements one is adding while iterating over it. Therefore, I believe most frameworks should expect this behavior (at least the ones cross smalltalk) which sounds the most correct. I think we should fix the world menu implementation and make the protocols consistent. Alternatively, we can let VW be a much more consistent Smalltalk environment than Pharo. What do you think ? The thing is to find alternative implementations that are efficient enough (no copy). Maybe we can get some inspirations from VW for that (how do they do BTW?). You should also check with other kinds of collection because they may act differently than OrderedCollection. So in the end it depends on the amount of effort needed to make all collections consistent with this new requirement and on the resulting overhead. If it's too much, I think that following the old advice don't modify a collection while iterating it is enough. If one really needs to do such kind of things he should consider an alternative design like using a zipper for example. Camille Clement
Re: [Pharo-dev] OrderedCollection protocols are broken: a potential fix
2014-09-03 14:44 GMT+02:00 Sven Van Caekenberghe s...@stfx.eu: I think we should change OrderedCollection#do: aBlock Override the superclass for performance reasons. firstIndex to: lastIndex do: [ :index | aBlock value: (array at: index) ] I agree. It's easier to read. But if you do that world menu does not work any more :-/ Clement, Do you happen to know exactly where the world menu building goes wrong ? I think so. The problem is in methods such as menuCommandOn: aBuilder worldMenu (aBuilder group: #SystemChanges) parent: #Tools; order: 0.51; with: [ (aBuilder item: #'Change Sorter') action:[self open]; icon: self taskbarIcon. (aBuilder item: #'Recover lost changes...') icon: Smalltalk ui icons recoverLostChangesIcon; action: [Smalltalk tools changeList browseRecentLog].]. aBuilder withSeparatorAfter. Here you have a with block which add other items to the menu. Then in the method PragmaMenuBuilder#interpretRegistration:, while iterating other the registrations, The code node with: block line 12 calls PragmaMenuBuilder#currentRoot:while: which activates the block, adding new elements to the collection it iterates from in PragmaMenuBuilder#interpretRegistration:. Be ready to use haltOnce / inspectOnce to debug these cases :-). Sven On 03 Sep 2014, at 13:51, Sven Van Caekenberghe s...@stfx.eu wrote: Clement, I am not sure, but could this not be a compiler issue ? Not with Opal but with the old compiler ?! I mean, if you look at the implementations of OrderedCollection#do: and OrderedCollection#collect: they basically do the same thing, going from firstIndex to lastIndex, both of which are instance variables, but in the first case, the #do:, the end test is evaluated on each iteration, while in the second case, the #to:do:, the end test should be evaluated only once. Since lastIndex changes while iterating, one iteration sees it, the other not. Looking at the byte codes seems to confirm that: the compilation of the #:to:do is different: Opal correctly moves both instance variables to temps, while the old compiler keeps on referring to the second instance variable (lastIndex) directly on each loop - which is plain wrong IMHO. I am with Marcus that you should not modify a collection that you iterate over. What if you would be inserting values at arbitrary places ? I am with you that both (all) enumerations should be consistent. Like in VW, delegating to the simplest #do: seems best. Sven On 03 Sep 2014, at 11:42, Clément Bera bera.clem...@gmail.com wrote: Hello guys, I was looking into the OrderedCollection protocols recently to see how well the sista optimizer perform with it methods, and I realized that this is completely broken. For example: col := #(1 2 3 4 5) asOrderedCollection. col do: [ :elem | elem trace . elem 4 ifTrue: [ col add: col size + 1 ]]. = '12345678' However: col := #(1 2 3 4 5) asOrderedCollection. col collect: [ :elem | elem trace . elem 4 ifTrue: [ col add: col size + 1 ]]. = '12345' This means that #do: and #reverseDo: iterate over all the elements of the collection,*including* the ones that you are adding while iterating over the collection, whereas all the other OrderedCollection protocols, such as #collect:, #select:, iterates over all the elements of the collection, *excluding* the ones you are adding while iterating over the collection. Marcus argued that one should not edit a collection while iterating over it, however this point is not valid as the World menu relies on this feature, using #do: to iterate over the elements of the OrderedCollection including the one it is adding while iterating over the collection. Changing the implementation makes the world menu display half of its items. I don't like this difference because it is inconsistent. For example, refactoring a #do: into a #collect: can simply not work because they do not iterate over the same elements if you are editing the collection while iterating over it. In VW, the protocols are consistent and iterating over a collection never iterates over the elements one is adding while iterating over it. Therefore, I believe most frameworks should expect this behavior (at least the ones cross smalltalk) which sounds the most correct. I think we should fix the world menu implementation and make the protocols consistent. Alternatively, we can let VW be a much more consistent Smalltalk environment than Pharo. What do you think ? Clement
[Pharo-dev] [pharo-project/pharo-core] d5f98f: 40199
Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: d5f98f303c8bfe7e4be72f9323a630415cca5b90 https://github.com/pharo-project/pharo-core/commit/d5f98f303c8bfe7e4be72f9323a630415cca5b90 Author: Jenkins Build Server bo...@pharo-project.org Date: 2014-09-03 (Wed, 03 Sep 2014) Changed paths: M ReleaseTests.package/ReleaseTest.class/instance/testing/testObsoleteClasses.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - scripts/script199.st A ScriptLoader40.package/ScriptLoader.class/instance/pharo - updates/update40199.st M ScriptLoader40.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: --- 40199 13947 fix testObsoleteClasses https://pharo.fogbugz.com/f/cases/13947 http://files.pharo.org/image/40/40199.zip
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/40199 Home: https://github.com/pharo-project/pharo-core
Re: [Pharo-dev] speed up with:do: by not checking size
2014-09-03 14:40 GMT+02:00 Marcus Denker marcus.den...@inria.fr: with:do: on SequencableCollection checks that both collections have the same size (it raises an Error if not). with: otherCollection do: twoArgBlock Evaluate twoArgBlock with corresponding elements from this collection and otherCollection. otherCollection size = self size ifFalse: [self error: 'otherCollection must be the same size']. 1 to: self size do: [:index | twoArgBlock value: (self at: index) value: (otherCollection at: index)] I think we should not do that: 1) it is slow Are you sure about that one? The check is a constant cost disregarding the collection length, and, anyway, self size is reused just after that. 2) when the other is larger, is would work and just omit the rest 3) if it is smaller, you will get an error anyway I have a feeling I'm not in Pharo anymore, but in R instead ;) Thierry There are just three methods doing such a size check: with:do: with:collect: reverseWith:do: (the last one actually raises a SizeMismatch exception, it is the sole user of that exception) Is there a reason why this makes sense? I added an issue with a slice to clean it up: https://pharo.fogbugz.com/f/cases/13946/speed-up-with-do-by-not-checking-size Marcus
Re: [Pharo-dev] Undeclared dictionary
one more question. How can you find out if method references a thing like that? Because if you do: #refersToLiteral: and pass a key from Undeclared you may also match a symbol which is completely ok. Is there a way to check only for variables? Uko On 03 Sep 2014, at 13:47, Marcus Denker marcus.den...@inria.fr wrote: On Wed, Sep 3, 2014 at 11:24 AM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi, can someone explain me how Undeclared dictionary works? So imagine you want to load code where a variable is not defined (e.g. due to loading old code, or because it references a variable that will only be loaded in a second step). In interactive mode, the compiler tells you. But in non-interactive mode (file in, mc load), it just loads the wrong code and for every undeclared variable, it adds an entry in the Undeclared dictionary. (the bytecode to read and write is the same as used for Globals and Class variables: pushLiteralVariable, which means push the value of the association, the store bytecode for assignment therefore is store in the value of that association. So if you actually run code that has Undeclared, it will work: it will be nil by default, but when you assign it will store into the Undeclared dictionary. When you add a new Global to the SystemDictionary, it will check Undeclared and move the value over. Same for Class vars. (this means that loading a class will automatically fix all Undeclared references to it) Because as I look at it, all the values are nil. Is it possible for them to be not nil? yes. Maybe we should have a “global variable comments” for this situations :) Ideed. -- Marcus Denker -- den...@acm.org http://www.marcusdenker.de
Re: [Pharo-dev] speed up with:do: by not checking size
On Wed, Sep 3, 2014 at 7:54 AM, Thierry Goubier thierry.goub...@gmail.com wrote: 2014-09-03 14:40 GMT+02:00 Marcus Denker marcus.den...@inria.fr: with:do: on SequencableCollection checks that both collections have the same size (it raises an Error if not). with: otherCollection do: twoArgBlock Evaluate twoArgBlock with corresponding elements from this collection and otherCollection. otherCollection size = self size ifFalse: [self error: 'otherCollection must be the same size']. 1 to: self size do: [:index | twoArgBlock value: (self at: index) value: (otherCollection at: index)] I think we should not do that: 1) it is slow Are you sure about that one? The check is a constant cost disregarding the collection length, and, anyway, self size is reused just after that. 2) when the other is larger, is would work and just omit the rest 3) if it is smaller, you will get an error anyway I have a feeling I'm not in Pharo anymore, but in R instead ;) +2. There are clear safety advantages in the check. If you want the faster protocol why not define withSomeOf:do: or some such? Thierry There are just three methods doing such a size check: with:do: with:collect: reverseWith:do: (the last one actually raises a SizeMismatch exception, it is the sole user of that exception) Is there a reason why this makes sense? I added an issue with a slice to clean it up: https://pharo.fogbugz.com/f/cases/13946/speed-up-with-do-by-not-checking-size Marcus -- best, Eliot
[Pharo-dev] How to see a Pharo job configuration - getting null pointer error?
Hi guys - I am trying to understand how some of the CI jobs work (in particular pharo launcher) - however when I click on the “Read Only Job Configuarion” link I just get an error screen with : java.lang.NullPointerException at org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:63) Further down the stack it mentions acegisecurity - so I’m assuming it might be related to some credential thing - but are we not allowed to see what scripts are run to create final images, or is something just misconfigured? Tim
Re: [Pharo-dev] Undeclared dictionary
Hi Uko, On Wed, Sep 3, 2014 at 8:16 AM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: one more question. How can you find out if method references a thing like that? Because if you do: #refersToLiteral: and pass a key from Undeclared you may also match a symbol which is completely ok. Is there a way to check only for variables? You check for the binding. e.g. self systemNavigation allCallsOn: (Undeclared bindingOf: #Foo) Are you sure refersToLiteral: answers true for a method that directly refers to a binding but not directly to its key? This sounds like a bug to me. Uko On 03 Sep 2014, at 13:47, Marcus Denker marcus.den...@inria.fr wrote: On Wed, Sep 3, 2014 at 11:24 AM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi, can someone explain me how Undeclared dictionary works? So imagine you want to load code where a variable is not defined (e.g. due to loading old code, or because it references a variable that will only be loaded in a second step). In interactive mode, the compiler tells you. But in non-interactive mode (file in, mc load), it just loads the wrong code and for every undeclared variable, it adds an entry in the Undeclared dictionary. (the bytecode to read and write is the same as used for Globals and Class variables: pushLiteralVariable, which means push the value of the association, the store bytecode for assignment therefore is store in the value of that association. So if you actually run code that has Undeclared, it will work: it will be nil by default, but when you assign it will store into the Undeclared dictionary. When you add a new Global to the SystemDictionary, it will check Undeclared and move the value over. Same for Class vars. (this means that loading a class will automatically fix all Undeclared references to it) Because as I look at it, all the values are nil. Is it possible for them to be not nil? yes. Maybe we should have a “global variable comments” for this situations :) Ideed. -- Marcus Denker -- den...@acm.org http://www.marcusdenker.de -- best, Eliot
Re: [Pharo-dev] How to see a Pharo job configuration - getting null pointer error?
I think you need an account to see the real config ... Please understand that we are all just users here, maintain/explaining jenkins/hudson is a PIA for all of us ;-) On 03 Sep 2014, at 17:26, Tim Mackinnon tim@testit.works wrote: Hi guys - I am trying to understand how some of the CI jobs work (in particular pharo launcher) - however when I click on the “Read Only Job Configuarion” link I just get an error screen with : java.lang.NullPointerException at org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:63) Further down the stack it mentions acegisecurity - so I’m assuming it might be related to some credential thing - but are we not allowed to see what scripts are run to create final images, or is something just misconfigured? Tim
Re: [Pharo-dev] speed up with:do: by not checking size
On 3 sept. 2014, at 17:26, Eliot Miranda eliot.mira...@gmail.com wrote: On Wed, Sep 3, 2014 at 7:54 AM, Thierry Goubier thierry.goub...@gmail.com wrote: 2014-09-03 14:40 GMT+02:00 Marcus Denker marcus.den...@inria.fr: with:do: on SequencableCollection checks that both collections have the same size (it raises an Error if not). with: otherCollection do: twoArgBlock Evaluate twoArgBlock with corresponding elements from this collection and otherCollection. otherCollection size = self size ifFalse: [self error: 'otherCollection must be the same size']. 1 to: self size do: [:index | twoArgBlock value: (self at: index) value: (otherCollection at: index)] I think we should not do that: 1) it is slow Are you sure about that one? The check is a constant cost disregarding the collection length, and, anyway, self size is reused just after that. 2) when the other is larger, is would work and just omit the rest 3) if it is smaller, you will get an error anyway I have a feeling I'm not in Pharo anymore, but in R instead ;) +2. There are clear safety advantages in the check. If you want the faster protocol why not define withSomeOf:do: or some such? Like Thierry I'm not sure that omitting the check brings a significant speedup. However, not doing this check follows the robustness principle: Be conservative in what you do, be liberal in what you accept from others. I would even be more liberal with a: 1 to: (self size min: otherCollection size) do: :) Thierry There are just three methods doing such a size check: with:do: with:collect: reverseWith:do: (the last one actually raises a SizeMismatch exception, it is the sole user of that exception) Is there a reason why this makes sense? I added an issue with a slice to clean it up: https://pharo.fogbugz.com/f/cases/13946/speed-up-with-do-by-not-checking-size Marcus -- best, Eliot
Re: [Pharo-dev] Undeclared dictionary
On 03 Sep 2014, at 17:29, Eliot Miranda eliot.mira...@gmail.com wrote: Hi Uko, On Wed, Sep 3, 2014 at 8:16 AM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: one more question. How can you find out if method references a thing like that? Because if you do: #refersToLiteral: and pass a key from Undeclared you may also match a symbol which is completely ok. Is there a way to check only for variables? You check for the binding. e.g. self systemNavigation allCallsOn: (Undeclared bindingOf: #Foo) Are you sure refersToLiteral: answers true for a method that directly refers to a binding but not directly to its key? This sounds like a bug to me. Hi My bad. I didn’t know that literal in this case is a full binding i.e. association. Thank you. Now I’ve got a bit smarter. Uko Uko On 03 Sep 2014, at 13:47, Marcus Denker marcus.den...@inria.fr wrote: On Wed, Sep 3, 2014 at 11:24 AM, Yuriy Tymchuk yuriy.tymc...@me.com wrote: Hi, can someone explain me how Undeclared dictionary works? So imagine you want to load code where a variable is not defined (e.g. due to loading old code, or because it references a variable that will only be loaded in a second step). In interactive mode, the compiler tells you. But in non-interactive mode (file in, mc load), it just loads the wrong code and for every undeclared variable, it adds an entry in the Undeclared dictionary. (the bytecode to read and write is the same as used for Globals and Class variables: pushLiteralVariable, which means push the value of the association, the store bytecode for assignment therefore is store in the value of that association. So if you actually run code that has Undeclared, it will work: it will be nil by default, but when you assign it will store into the Undeclared dictionary. When you add a new Global to the SystemDictionary, it will check Undeclared and move the value over. Same for Class vars. (this means that loading a class will automatically fix all Undeclared references to it) Because as I look at it, all the values are nil. Is it possible for them to be not nil? yes. Maybe we should have a “global variable comments” for this situations :) Ideed. -- Marcus Denker -- den...@acm.org http://www.marcusdenker.de -- best, Eliot
Re: [Pharo-dev] speed up with:do: by not checking size
On Wed, Sep 3, 2014 at 8:37 AM, Camille Teruel camille.ter...@gmail.com wrote: On 3 sept. 2014, at 17:26, Eliot Miranda eliot.mira...@gmail.com wrote: On Wed, Sep 3, 2014 at 7:54 AM, Thierry Goubier thierry.goub...@gmail.com wrote: 2014-09-03 14:40 GMT+02:00 Marcus Denker marcus.den...@inria.fr: with:do: on SequencableCollection checks that both collections have the same size (it raises an Error if not). with: otherCollection do: twoArgBlock Evaluate twoArgBlock with corresponding elements from this collection and otherCollection. otherCollection size = self size ifFalse: [self error: 'otherCollection must be the same size']. 1 to: self size do: [:index | twoArgBlock value: (self at: index) value: (otherCollection at: index)] I think we should not do that: 1) it is slow Are you sure about that one? The check is a constant cost disregarding the collection length, and, anyway, self size is reused just after that. 2) when the other is larger, is would work and just omit the rest 3) if it is smaller, you will get an error anyway I have a feeling I'm not in Pharo anymore, but in R instead ;) +2. There are clear safety advantages in the check. If you want the faster protocol why not define withSomeOf:do: or some such? Like Thierry I'm not sure that omitting the check brings a significant speedup. However, not doing this check follows the robustness principle: Be conservative in what you do, be liberal in what you accept from others. But it violates the if it ain't broke don't fix it, it means what it means, and Smalltalk is a safe language principles. That safety check finds bugs. If one wants a more relaxed contract, implement a new contract, don't break an existing contract that has stood for years. I would even be more liberal with a: 1 to: (self size min: otherCollection size) do: :) But you can write that if that's what you mean. But arbitrarily changing existing protocol for weak reasons when _it ain't broke_ is a recipe for chaos. Thierry There are just three methods doing such a size check: with:do: with:collect: reverseWith:do: (the last one actually raises a SizeMismatch exception, it is the sole user of that exception) Is there a reason why this makes sense? I added an issue with a slice to clean it up: https://pharo.fogbugz.com/f/cases/13946/speed-up-with-do-by-not-checking-size Marcus -- best, Eliot -- best, Eliot
Re: [Pharo-dev] How to see a Pharo job configuration - getting null pointer error?
Believe me, I understand the PIA part of CI ;) You are right about the account though. I do have an account - so I tried logging in to ci.inria.fr - and I get a dashboard to navigate down to Pharo-contributions, but clicking the jenkins button for that project gives me the https://ci.inria.fr/pharo-contribution/? link I’ve been used to. I wonder if something is misconfigured (or maybe we just aren’t allowed to see how a job is configured?). I wanted to know, because the images that PharoLauncher produces for end users seem different from the ones spit out of the normal jenkins CI. So I think there must be some script run at the very end, which I wanted to understand. Tim On 3 Sep 2014, at 16:33, Sven Van Caekenberghe s...@stfx.eu wrote: I think you need an account to see the real config ... Please understand that we are all just users here, maintain/explaining jenkins/hudson is a PIA for all of us ;-) On 03 Sep 2014, at 17:26, Tim Mackinnon tim@testit.works wrote: Hi guys - I am trying to understand how some of the CI jobs work (in particular pharo launcher) - however when I click on the “Read Only Job Configuarion” link I just get an error screen with : java.lang.NullPointerException at org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:63) Further down the stack it mentions acegisecurity - so I’m assuming it might be related to some credential thing - but are we not allowed to see what scripts are run to create final images, or is something just misconfigured? Tim
[Pharo-dev] Why doesn't the OSX vm show the name of the running image?
I’m wondering if there is a particular reason why the VM on OSX, just shows the name of the .app file and not the running image? I’ve downloaded the recent 3.0 vm, and used it to launch two images (I set it as the default app and double clicked on 2 different images) - and when you do a CMD-Tab, its a bit confusing because all you see are two apps that say “Pharo 3.0” - so its hard to distinguish between them. It may be an OSX limitation - but I thought it was worth asking. I can create a fogbugz if anyone thinks its worthy. Tim
Re: [Pharo-dev] speed up with:do: by not checking size
This check is not in a loop so I don't think it is performance critical... I don't know if this change is great. 2014-09-03 16:54 GMT+02:00 Thierry Goubier thierry.goub...@gmail.com: 2014-09-03 14:40 GMT+02:00 Marcus Denker marcus.den...@inria.fr: with:do: on SequencableCollection checks that both collections have the same size (it raises an Error if not). with: otherCollection do: twoArgBlock Evaluate twoArgBlock with corresponding elements from this collection and otherCollection. otherCollection size = self size ifFalse: [self error: 'otherCollection must be the same size']. 1 to: self size do: [:index | twoArgBlock value: (self at: index) value: (otherCollection at: index)] I think we should not do that: 1) it is slow Are you sure about that one? The check is a constant cost disregarding the collection length, and, anyway, self size is reused just after that. 2) when the other is larger, is would work and just omit the rest 3) if it is smaller, you will get an error anyway I have a feeling I'm not in Pharo anymore, but in R instead ;) Thierry There are just three methods doing such a size check: with:do: with:collect: reverseWith:do: (the last one actually raises a SizeMismatch exception, it is the sole user of that exception) Is there a reason why this makes sense? I added an issue with a slice to clean it up: https://pharo.fogbugz.com/f/cases/13946/speed-up-with-do-by-not-checking-size Marcus
Re: [Pharo-dev] Why doesn't the OSX vm show the name of the running image?
Tim Mackinnon wrote: I’m wondering if there is a particular reason why the VM on OSX, just shows the name of the .app file and not the running image? I’ve downloaded the recent 3.0 vm, and used it to launch two images (I set it as the default app and double clicked on 2 different images) - and when you do a CMD-Tab, its a bit confusing because all you see are two apps that say “Pharo 3.0” - so its hard to distinguish between them. It may be an OSX limitation - but I thought it was worth asking. I can create a fogbugz if anyone thinks its worthy. Tim It would be nice for those icons to show the image name, but all the other applications I have open also don't show the names of their open documents/content. ???
Re: [Pharo-dev] speed up with:do: by not checking size
Marcus the contract is important and should be explicit because if you do not check the same size then you may have part of the computation done and not the rest. So I would introduce new methods with explicit names telling that fuzzyWith:do: or soemthing like that. On 3/9/14 14:40, Marcus Denker wrote: with:do: on SequencableCollection checks that both collections have the same size (it raises an Error if not). with: otherCollection do: twoArgBlock Evaluate twoArgBlock with corresponding elements from this collection and otherCollection. otherCollection size = self size ifFalse: [self error: 'otherCollection must be the same size']. 1 to: self size do: [:index | twoArgBlock value: (self at: index) value: (otherCollection at: index)] I think we should not do that: 1) it is slow 2) when the other is larger, is would work and just omit the rest 3) if it is smaller, you will get an error anyway There are just three methods doing such a size check: with:do: with:collect: reverseWith:do: (the last one actually raises a SizeMismatch exception, it is the sole user of that exception) Is there a reason why this makes sense? I added an issue with a slice to clean it up: https://pharo.fogbugz.com/f/cases/13946/speed-up-with-do-by-not-checking-size Marcus
Re: [Pharo-dev] speed up with:do: by not checking size
Like Thierry I'm not sure that omitting the check brings a significant speedup. However, not doing this check follows the robustness principle: Be conservative in what you do, be liberal in what you accept from others. But it violates the if it ain't broke don't fix it, it means what it means, and Smalltalk is a safe language principles. That safety check finds bugs. If one wants a more relaxed contract, implement a new contract, don't break an existing contract that has stood for years. I would even be more liberal with a: 1 to: (self size min: otherCollection size) do: :) But you can write that if that's what you mean. But arbitrarily changing existing protocol for weak reasons when _it ain't broke_ is a recipe for chaos. + 1 Stef
[Pharo-dev] latex exporter in Pillar
Hi!
I am currently investigating whether Pillar may be used for the
AgileVisualization book.
I am interested in exporting to PDF and Latex. I have tried the command:
./pillar export —to=latex first.pier first.tex
But the generated .tex file is not valid since it contains a line:
-=-=-=-=
\newcommand{\ct}[1]}
-=-=-=-=
Will this be fixed ?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] latex exporter in Pillar
Have you used the template files ? I used for my own book, took the files
from Update Pharo By Example and it worked like a charm including creation
CI job and even pushing the book to gitbook. Tex files, pdf files and MD
files generated without any issues. Also working with Updated PBE I never
had an issue with bad tex generation.
On Wed, Sep 3, 2014 at 10:24 PM, Alexandre Bergel alexandre.ber...@me.com
wrote:
Hi!
I am currently investigating whether Pillar may be used for the
AgileVisualization book.
I am interested in exporting to PDF and Latex. I have tried the command:
./pillar export —to=latex first.pier first.tex
But the generated .tex file is not valid since it contains a line:
-=-=-=-=
\newcommand{\ct}[1]}
-=-=-=-=
Will this be fixed ?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-dev] OrderedCollection protocols are broken: a potential fix
Clement we should fix the code of the menu :) Stef On 3/9/14 15:25, Clément Bera wrote: Hello, Sven you are right, the old compiler was consistent in the sense that it always iterated over all the elements, including the ones added with #add: and #addLast: while iterating over the collection. On the other hand, VW is consistent with the Opal implementation for #to:do: in the sense that they iterate only on the elements of the collection excluding the ones added while iterating. #add:after: and co do not work well if you edit the collection while iterating over it for sure :). It's too late for don't modify a collection while iterating it because the system does it, for example, to build the world menu. So I think the solution is in two steps: - removing code which edit the collection while iterating over it. As most frameworks work both on Pharo and VW and that the behavior is different I think there shouldn't be that much, so fixing the Pharo image may be enough. - be consistent in our collection protocol, basically by rewriting do: and reverseDo: like that: FROM: do: aBlock Override the superclass for performance reasons. | index | index := firstIndex. [index = lastIndex] whileTrue: [aBlock value: (array at: index). index := index + 1] TO: do: aBlock Override the superclass for performance reasons. firstIndex to: lastIndex do: [ :index | aBlock value: (array at: index) ] 2014-09-03 14:05 GMT+02:00 Camille Teruel camille.ter...@gmail.com mailto:camille.ter...@gmail.com: On 3 sept. 2014, at 11:42, Clément Bera bera.clem...@gmail.com mailto:bera.clem...@gmail.com wrote: Hello guys, I was looking into the OrderedCollection protocols recently to see how well the sista optimizer perform with it methods, and I realized that this is completely broken. For example: col := #(1 2 3 4 5) asOrderedCollection. col do: [ :elem | elem trace . elem 4 ifTrue: [ col add: col size + 1 ]]. = '12345678' However: col := #(1 2 3 4 5) asOrderedCollection. col collect: [ :elem | elem trace . elem 4 ifTrue: [ col add: col size + 1 ]]. = '12345' This means that #do: and #reverseDo: iterate over all the elements of the collection,*including* the ones that you are adding while iterating over the collection, whereas all the other OrderedCollection protocols, such as #collect:, #select:, iterates over all the elements of the collection, *excluding* the ones you are adding while iterating over the collection. Marcus argued that one should not edit a collection while iterating over it, however this point is not valid as the World menu relies on this feature, using #do: to iterate over the elements of the OrderedCollection including the one it is adding while iterating over the collection. Changing the implementation makes the world menu display half of its items. I don't like this difference because it is inconsistent. For example, refactoring a #do: into a #collect: can simply not work because they do not iterate over the same elements if you are editing the collection while iterating over it. In VW, the protocols are consistent and iterating over a collection never iterates over the elements one is adding while iterating over it. Therefore, I believe most frameworks should expect this behavior (at least the ones cross smalltalk) which sounds the most correct. I think we should fix the world menu implementation and make the protocols consistent. Alternatively, we can let VW be a much more consistent Smalltalk environment than Pharo. What do you think ? The thing is to find alternative implementations that are efficient enough (no copy). Maybe we can get some inspirations from VW for that (how do they do BTW?). You should also check with other kinds of collection because they may act differently than OrderedCollection. So in the end it depends on the amount of effort needed to make all collections consistent with this new requirement and on the resulting overhead. If it's too much, I think that following the old advice don't modify a collection while iterating it is enough. If one really needs to do such kind of things he should consider an alternative design like using a zipper for example. Camille Clement
Re: [Pharo-dev] latex exporter in Pillar
Hi Alex,
Could you describe the steps you took?
Cheers,
Doru
On Wed, Sep 3, 2014 at 9:34 PM, kilon alios kilon.al...@gmail.com wrote:
Have you used the template files ? I used for my own book, took the files
from Update Pharo By Example and it worked like a charm including creation
CI job and even pushing the book to gitbook. Tex files, pdf files and MD
files generated without any issues. Also working with Updated PBE I never
had an issue with bad tex generation.
On Wed, Sep 3, 2014 at 10:24 PM, Alexandre Bergel alexandre.ber...@me.com
wrote:
Hi!
I am currently investigating whether Pillar may be used for the
AgileVisualization book.
I am interested in exporting to PDF and Latex. I have tried the command:
./pillar export —to=latex first.pier first.tex
But the generated .tex file is not valid since it contains a line:
-=-=-=-=
\newcommand{\ct}[1]}
-=-=-=-=
Will this be fixed ?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
--
www.tudorgirba.com
Every thing has its own flow
