Re: [Pharo-project] Feedback about SmallLint
On 21 April 2012 14:00, Mariano Martinez Peck marianop...@gmail.com wrote: 2) RBContainsRule is not clear for me. 'Checks for the common code fragment: (aCollection detect: [:each | ''some condition''] ifNone: [nil]) ~= nil. contains: can simplify this code to aCollection contains: [:each | ''some condition'']. Not only is the contains: variant shorter, it better signifies what the code is doing.' That is not very true. #contains answers true or false, while detect:ifNone:[] answers whatever, and in your example it is nil. So, the answer will be different and hence it is not the same. Ok, in your example, you compare after with == nil... but... I don't really see a use case. For example, in my case it detected: classNamed: className ^ (migrations detect: [:m | m sourceClassName = className ] ifNone: [ ^ self globalClassNamed: className ]) targetClass. Thank you for pointing out. I have previously seen similar issues with this rule. I committed an improved version that should return less false-positives, and that finds a few more related issues. 3) RBLawOfDemeterRule: maybe you can exclude string concatenation? (#,) because it detected a lot of messages like this: signalWith: aGlobalName and: aSelector ^ self signal: 'Method ', aGlobalName, '#', aSelector, ' not found.' Also, what about excluding messages like #asXXX. For example, here it detected self signature asByteArray. Is that completly breaking the law of demeter? mmm I don't think so. verifySignatureFrom: aDecoder | streamSignature | streamSignature := ByteArray new: self signature size. aDecoder nextEncodedBytesInto: streamSignature. (self signature asByteArray = streamSignature) ifFalse: [ FLBadSignature signalCurrentSignature: self signature streamSignature: streamSignature ]. Arguably this is a problem in your code: You could for example use streams or a formatter to build complicated strings; and you could ask the signature if it is the same as a stream signature. It is kind of arbitrary from when on a chain of selectors is considered a violation of the law of demeter ... Maybe the number should be higher? Maybe this number should be even different if these are unary, binary or keyword messages? As with any violation this is just a suggestion. 4) RBSentNotImplementedRule: I didn't understand why it has selected: largeIdentityHash primitive: 75 self primitiveFailed both messages are implemented :( The rule checks if self-sends are implemented in the class hierarchy, and if super-sends are implemented in the superclass hierarchy of the method. For example, when you inherit from ProtoObject then #primitiveFailed is not implemented. In your case the problem might never show up in practice -- for example because your class is abstract and all subclasses implement the message; or because you use #doesNotUnderstand: -- but still I think the rule is correct. 5) RBClassInstVarNotInitializedRule could be smarter and search not only for #initialize but for #initializeXXX. Lots of times, I initialize my objects with data, using a particular nitialize method, such as: initializeWithBehaviors: someBehaviors extensionMethods: someExtensionMethods so the rule says there is no initialize...but I have that one ;) The rule only checks for the presence of an #initialize method (the only method that is automatically called by the system upon loading of a class) if the class defines variables. It does not check if (and where) the variable is actually assigned. Now if you have classes initialize each other or if you initialize your variables lazily that rule complains. I agree with the author of the rule that this is bad style and worth to think about. That's all the feedback so far. It helped me to find some things to improve so thanks! Please don't call it SmallLint. Since at least 2003 the tool is called Smalltalk Code Critics, see for example http://www.cincomsmalltalk.com/blog/blogView?entry=3236371324. I think it has been renamed even before 2000, but I can't find the slides of John anymore. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] 1.4, seaside, comet, how to get it working
But I think I more or less begin to understand: some Seaside (client) code wants to access the underlying socket stream to the client ? For reading and/or for writing ? Inside or outside an existing request/response ? Inside or outside the dynamic context of the request handling ? For writing only, see WAListenerAdaptor in Seaside-Adaptors-Comanche. WAListenerAdaptor is a custom server implementation that uses Kom for some utility functions. It enables Seaside to directly write to the Socket and to keep the response open as longs as Seaside needs (to stream contents). Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] [update 1.3] #13321
Thank you for working on Pharo 1.3 :-) On 15 February 2012 14:16, Marcus Denker marcus.den...@inria.fr wrote: 13321 - Issue 5228: MorphTreeMorph hide last element when horizontal scrollbar is shown http://code.google.com/p/pharo/issues/detail?id=5228 Issue 4840: Schedulebetween:and:do can iterate over the wrong dates. http://code.google.com/p/pharo/issues/detail?id=4840 -- Marcus Denker -- http://marcusdenker.de -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] moved repos to gemstone
Regarding the refactoring engine: I will continue to maintain the code in the spirit of the original authors in my own repository. Of course Pharo is free to fork any open-souce repository, but then the maintainers should not complain if they end up with outdated and broken code nobody has time to maintain (as it recently happend with the one-click builder). Furthermore, it would be appreciated if the projects were renamed and and would use a different namespace. For example, I cannot load any package that depends on the official version of FS. A quick comparison shows that the Pharo fork is based on outdated code and has some methods of the public API renamed. Lukas On Wednesday, February 15, 2012, Camillo Bruni camillobr...@gmail.com wrote: If the corresponding project admins would agree it would be cool to move the development to ss3 on gemstone of the following projects I ported so far: - Citezen http://ss3.gemstone.com/ss/citezen - FSFilesystem http://ss3.gemstone.com/ss/fs - FSGit http://ss3.gemstone.com/ss/fs-git - PetitMarkdown http://www.squeaksource.com/PetitMarkdown - PharoRB http://ss3.gemstone.com/ss/rb-pharo - Refactoring Enginehttp://ss3.gemstone.com/ss/rb - Soup http://ss3.gemstone.com/ss/soup - XMLSupporthttp://ss3.gemstone.com/ss/xmlsupport I tried to add people from the old projects as admins Please let me know -- Lukas Renggli (mobile) http://www.lukas-renggli.ch
Re: [Pharo-project] moved repos to gemstone
A quick comparison shows that the Pharo fork is based on outdated code and has some methods of the public API renamed. where's the other code located? I would like to check that. http://source.wiresong.ca/mc Me too especially because I committed in FS on squeak source and not in Pharo so that colin can commit. Because originally I worked on PharoTaskForces. This is not how open-source works [1, 2]. Not even Pharo works like this. In addition I do not see how we can control our life if we cannot publish on the repository of a part that should be central to us. I understand that you want to change things. Also I understand that the original project might be too slow, or that the authors might not accept your changes. In this case it is only fair to do a proper fork [3], to choose a new name, and a new namespace. And to live with all the consequences. Lukas [1] http://producingoss.com/en/getting-started.html#developer-guidelines [2] http://subversion.apache.org/docs/community-guide/general.html [3] http://producingoss.com/en/forks.html#forks-initiating -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Feedback from lecture :(
students in the lecture on windows downloaded cogvm I do not from where… and used pharo1.3 and some experienced crashes. This has been reported at least 10 times per week since the last 6 months. The VMs of the one click are FUC.. old and buggy. If nobody have time to make a new one click (we are all busy), please please please, remove it from the website. We give so much bad impression. It is worst than having no one click. You cannot say that, because I updated the One-Click distribution less than a month ago: https://github.com/renggli/builder/commit/7623726096db2e3fa58eefe267c62ba171049a83 People using this code get the latest available CogVM. The problem is that Pharo maintains its own unmaintained fork. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Regular expression
VB-Regexp does not support any of the following common regular expression features: lookahead, lookbehind, recursion, multiplicity ranges, non-greedy quantifier, shy groups, directives, conditionals, named captures, back references, and comments. You can (conceptually) do all this with PetitParser, but then you are not writing a regular expression anymore but a (PEG) parser. There was once a plugin that called an external regular expression library (I think it used the library Perl is using) that supported the features you are looking for. Lukas On 11 February 2012 23:27, recursiv...@gmail.com wrote: Hi, Is it possible to use the VB-Regexp package to construct a single regular expression that ensures a string is alphanumeric and contains both at least one number and alphabetic character. Looking at the regexp package and documentation it doesn't appear so. In javascript or perl you use something like this with lookahead assertions: ^(?=.*[a-zA-Z])(?=.*[0-9]).*$ I have something working using multiple regexp's but wondered if a more typical regexp was possible using the package ? Thanks -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Regular expression
Yes, in this particular example one can rewrite the expression as ^.*(([a-zA-Z].*[0-9])|([0-9].*[a-zA-Z])).*$ and it (probably) does the same. However, this cannot be done in a general case, because lookahead are not part of the (currently) recognizable types of languages with VB-Regexp. It shouldn't be too difficult to add positive and negative lookahead to VB-Regexp (this is essentially like #and and #not in PetitParser), but getting the semantics exactly right is more tricky. Lukas On 12 February 2012 15:40, Stéphane Ducasse stephane.duca...@inria.fr wrote: thanks for the update. Now may be the problem can be still express with regex. Stef On Feb 12, 2012, at 10:49 AM, Lukas Renggli wrote: VB-Regexp does not support any of the following common regular expression features: lookahead, lookbehind, recursion, multiplicity ranges, non-greedy quantifier, shy groups, directives, conditionals, named captures, back references, and comments. You can (conceptually) do all this with PetitParser, but then you are not writing a regular expression anymore but a (PEG) parser. There was once a plugin that called an external regular expression library (I think it used the library Perl is using) that supported the features you are looking for. Lukas On 11 February 2012 23:27, recursiv...@gmail.com wrote: Hi, Is it possible to use the VB-Regexp package to construct a single regular expression that ensures a string is alphanumeric and contains both at least one number and alphabetic character. Looking at the regexp package and documentation it doesn't appear so. In javascript or perl you use something like this with lookahead assertions: ^(?=.*[a-zA-Z])(?=.*[0-9]).*$ I have something working using multiple regexp's but wondered if a more typical regexp was possible using the package ? Thanks -- Lukas Renggli www.lukas-renggli.ch -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] [update 1.4] #14314
- there should be :D (I imagine it exactly like in eclipse, cmd-key pressed = underline all links and display a hand cursor onOver) - telling morphic to do highlighting is a different story |-( - right now you only get onDrag events in – although named onMove – I guess I will have to hack a bit :) - right-click menus should start working again (they're currently slightly broken) - we should have refactoring menus in there (rename instVar/args, push instvar...) Most of these things have been done in Helvetia. The next most useful thing after code navigation was on-the-fly Code Critics with the yellow wiggly underlines and Ctrl+1 instant-fix. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] About linkedlist
See below for an alternative collection implementation: http://jenkins.lukas-renggli.ch/job/Container/ Also contains a nice double-linked-list, as well as many other standard containers that are missing in standard Smalltalk. Lukas On 3 February 2012 07:52, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi I was thinking that linkedList is really not to be used by something else than the scheduler (remember the problem we got with change == into something else). So I was wondering if it would not be simpler/safer to design a generalPurpose fast/robust LinkedList too? Stef -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] About linkedlist
This is all very much at an experimental phase. what is the diff between arrayList and vectorList ? ArrayList is double ended (very much like OrderedCollection), VectorList is single ended. I was just experimenting to see if it makes a difference. Do you have some kind of high level description of Container explaining the rationale, ideas and approach. The core idea is to split iteration from containment; I think a horrible design mistake in the Smalltalk-80 collections. Do you have some kind of high level description of Container explaining the rationale, ideas and approach. It is one thing to browse the code, but the why/how is important as a guide. Another idea is to split the backing store from the container and allow the composition of collection properties: - uniqueness: yes, no - order: natural, custom, indexed - access: indexed, keyed - structure: hashed, treed, linked - weakness: yes, no (not even touched yet) It seems that although you introduce iterators, they are less annoying then expected, which is great. The goal here is to be as lazy as possible and avoid unnecessary loops over the collections. Also iterators avoid the explosion of selector combinations like (#do: and #withIndexDo: and #withIndexCollect:, etc) by utilizing objects. Also, a certain level of backwards compatibility seems to be present, looking at message names. I like the existing names, but then this is not a goal. Also I am not sure if methods like #add: and #at:put: should really return the argument. Essentially the goal is to provide an alternative to the Smalltalk-80 collections by adopting some ideas from modern collection libraries in Java, C++, Scala, Haskell, etc. Lukas On 3 February 2012 10:07, Stéphane Ducasse stephane.duca...@inria.fr wrote: what is the diff between arrayList and vectorList ? I have plenty of other questions. :) Stef On Feb 3, 2012, at 9:26 AM, Lukas Renggli wrote: See below for an alternative collection implementation: http://jenkins.lukas-renggli.ch/job/Container/ Also contains a nice double-linked-list, as well as many other standard containers that are missing in standard Smalltalk. Lukas On 3 February 2012 07:52, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi I was thinking that linkedList is really not to be used by something else than the scheduler (remember the problem we got with change == into something else). So I was wondering if it would not be simpler/safer to design a generalPurpose fast/robust LinkedList too? Stef -- Lukas Renggli www.lukas-renggli.ch -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] About linkedlist
what is the diff between arrayList and vectorList ? ArrayList is double ended (very much like OrderedCollection), VectorList is single ended. I was just experimenting to see if it makes a difference. ok. I like to see such kind of experiment. Was the name based on something that people use? No, it is a randomly chosen and meaningless name. I guess in the end there will only be one named ArrayList, but I am not sure which implementation is better. Just a note to the VM developers: The primitive Array#replaceFrom:to:with:startingAt: is absolutely central to the implementation of efficient collections. While it works well if you copy from one array to the other, it is broken if source and destination array are the same and the areas overlap. Would it be possible to fix this. Even memmove(void*, void*, size_t) in C can handle this situation correctly. Do you have some kind of high level description of Container explaining the rationale, ideas and approach. The core idea is to split iteration from containment; I think a horrible design mistake in the Smalltalk-80 collections. I thought about that when I read the Iterator. I would not say that this is horrible. I think that for default case this is not that bad. Now when you want to navigate a large graph and control the navigation then you should have an iterator. I think it is pretty horrible. I can think of at least 4 meaningful ways to iterate over an simple array (for other collections there are even more ways): 1. forward: #do:, #collect:, #select:, #detect:, #inject:into:, ... 2. forward with index: #keysAndValuesDo:, #collectWithIndex:, everything else is not possible 3. backward: #reverseDo:, everything else is not possible 4. backward with index: not possible If you split the iterator into a separate object, suddenly all of this becomes trivial. A #collect: remains a #collect: no matter if you are going forward or backward, or with or without index. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] [Vm-dev] Re: About linkedlist
what is the diff between arrayList and vectorList ? ArrayList is double ended (very much like OrderedCollection), VectorList is single ended. I was just experimenting to see if it makes a difference. ok. I like to see such kind of experiment. Was the name based on something that people use? No, it is a randomly chosen and meaningless name. I guess in the end there will only be one named ArrayList, but I am not sure which implementation is better. Just a note to the VM developers: The primitive Array#replaceFrom:to:with:startingAt: is absolutely central to the implementation of efficient collections. While it works well if you copy from one array to the other, it is broken if source and destination array are the same and the areas overlap. Would it be possible to fix this. Even memmove(void*, void*, size_t) in C can handle this situation correctly. The problems are that the primitive is defined to be destructive, and code could be depending on the destructive update behaviour. Would it be feasible to use a new primitive that did the right thing in the case of overlap, or do you definitely want to change primitive 105? A new primitive would be prefect. Like this we can even have a nice fallback in case the VM doesn't have the primitive yet. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] MCWorkingCopy#uniqueVersionName
Ironically this proposition would make some Monticello operations slower, because Monticello will need to download and open all versions with the same name to figure out if the ancestry matches. Furthermore, this would subtly break many tools, because most of them do not look at the ancestry but only at the filename (again to make it fast). Last but not least, the proposal will annoy people that want to integrate changes and that cannot because a file with that name is already in their repository. Can we then do nothing at all ? Commit speed has never been a problem to me. What about changing the naming, like adding an extra UUID to the name ? That would have been a solution before all tools started to depend on the naming. Don't _you_ have any ideas about speeding up Monticello ? Use Monticello 2 that addresses this and many other problems of Monticello 1. But then people also criticize Monticello 2 because it addresses this problem, and version data is not human readable anymore. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] MCWorkingCopy#uniqueVersionName
Would it not be possible to assign the version name based on local, best effort knowledge alone and deal with possible conflicts afterwards (there is the ancestory) ? to me that would make more sense. - Is it necessary that the version name is globally unique? I doubt so. - Having it unique per repository should be enough, no? Ironically this proposition would make some Monticello operations slower, because Monticello will need to download and open all versions with the same name to figure out if the ancestry matches. Furthermore, this would subtly break many tools, because most of them do not look at the ancestry but only at the filename (again to make it fast). Last but not least, the proposal will annoy people that want to integrate changes and that cannot because a file with that name is already in their repository. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] about push up IV
On 18 January 2012 21:15, Stéphane Ducasse stephane.duca...@inria.fr wrote: Ok I see I should select the variable but if I select the class I do not need to see superclass variables because I should not been able to push them. I find it convenient to be able to push up any variable in the hierarchy from any subclass ... So this is intentional. Ok I see so this is push from your place to superclass. No, it always pushes up to the superclass of where the class is defined in. What I got is that doing a pull and after the inverse the class var was lost. I did not try to reproduce it but I added at end. Pull down is not the inverse of push up, because it only adds it to the subclasses where the variable is actually needed. BTW I thought about one cool refactoring this is push as subclassResponsibility :). Refactor class Realize I would call it abstractize because in general I have the concrete method. and Realize does not says that. Not sure if such a word exists at all? Also the refactoring does the opposite: it makes an abstract class real, that is it implements all the abstract methods of the superclasses (see the explanation in the tooltip help). Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] about push up IV
Hi Stef, Depends on where you trigger the refactoring from. You only get a list of instance variables when you trigger the refactoring from the class. You can avoid the extra step if you use the variable browser, or you select the variable in the source code. Lukas On 18 January 2012 20:46, Stéphane Ducasse stephane.duca...@inria.fr wrote: Hi lukas may be you already fixed it. Now when I push up a instance variables I get prompted with the complete list of instance variables even the ones of the superclasses. Stef -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] about push up IV
On 18 January 2012 21:15, Stéphane Ducasse stephane.duca...@inria.fr wrote: Ok I see I should select the variable but if I select the class I do not need to see superclass variables because I should not been able to push them. I find it convenient to be able to push up any variable in the hierarchy from any subclass ... So this is intentional. BTW I thought about one cool refactoring this is push as subclassResponsibility :). Refactor class Realize Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] First steps making OB work in 1.4
Please note that this configuration loads completely outdated code from last summer. Lukas On 17 January 2012 17:26, Esteban Lorenzano esteba...@gmail.com wrote: great guille! El 17/01/2012, a las 1:19p.m., Guillermo Polito escribió: Hi! I've been working the last days in making OB work in pharo 1.4. I updated several deprecations like method reference and stuff and discovered some bugs that I've already published in: http://code.google.com/p/pharo/issues/detail?id=5189q=milestone%3D1.4colspec=ID%20Type%20Status%20Summary%20Milestone%20Difficulty http://code.google.com/p/pharo/issues/detail?id=5183q=milestone%3D1.4colspec=ID%20Type%20Status%20Summary%20Milestone%20Difficulty I've already proposed some fixes for them, but if anyone can have a look too I'll feel better :). Those fixes are needed in order to load OB. Meanwhile, you can also have some patches from the cs and fileout I attach. What's working now? OB + OCompletion + Shout + Sunit integration. So, It's everything but Refactoring browser, which is a little more difficult since there is another RB version loaded in the image :P. To load it (after integrating the patches): Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfOmniBrowser'; load. (ConfigurationOfOmniBrowser project version: #stable) load: #( 'Core Tests' 'OCompletion Tests' ) , #( 'Core' 'OB-SUnitIntegration' 'OB-Shout' 'OCForOB'). Cheers, Guille pluggable list morph fix.1.csSlider-setValue.st -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] SmallLint
One could also think on how to efficiently visualize the results of smallLint ... See for example the SmallLint results of Seaside 3.0 run by Jenkins: http://jenkins.lukas-renggli.ch/job/Seaside%203.0/791/checkstyleResult/. How simon can help concretely? Make it possible so that code critics can run on-the-fly in the code editors (pretty standard in any IDE today). I had that in Helvetia, but that code depends on the whole Helvetia stack depends on the old editor. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Method recategorization proposal for TestCase class
#packageNamesUnderTest is only called from *sunitgui. In fact there should be no such method in TestCase class at all. In my image there is none. Lukas On 15 January 2012 15:36, Nicolás Paez nicop...@gmail.com wrote: Hi people, I was trying to measure coverage of my code and I realized the method TestCase classpackageNamesUnderTest belogs to a category called *sunitgui, shouldn't it belong to coverage category? I was about opening an issue for this, but I wanted to check it first because maybe there is a reason I don't understand. Regards, Nico. blog: nicopaez.wordpress.com -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)
if the Cusp folks can have an Eclipse plugin using swank to talk to an SBCL image, I see no impediment to doing the same for Smalltalk: swank provides a common image-side adapter, and to that you can attach your Eclipse, IntelliJ, emacs... or just a plain old SSH connection. Some Smalltalk folks (GemStone) have that already: http://karpisek.net/gemdev/ Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Finding all places where a class is instantiated?
Depends on how you use your classes. If you have have a finite set of constructor methods you can use 'Refactor Search code...' with something like this: RBParseTreeSearcher new matches: 'PluggableButtonMorph on: `@.arg1' do: [ :node :answer | node ]; matches: 'PluggableButtonMorph on: `@.arg1 getState: `@.arg2 action: `@.arg3' do: [ :node :answer | node ]; yourself Of course, if you put all your constructor methods into a distinct protocol, you could automate the creation of the searcher. Lukas On 15 January 2012 17:28, Stefan Marr smallt...@stefan-marr.de wrote: Hi: When refactoring code, I frequently try to find all places where a class is instantiated. Is there anything in the image which would work a bit more precise than a search for the class name in the finder? Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Finding all places where a class is instantiated?
I've added a refactoring scope 'Refactoring Scope Instantiations' that finds all the places where a method is sent to the selected class that eventually ends up in #basicNew or #basicNew:. If you don't use reflection this gives better and less false-positives than just the class references. Lukas On 15 January 2012 19:29, Mariano Martinez Peck marianop...@gmail.com wrote: On Sun, Jan 15, 2012 at 7:10 PM, Stefan Marr smallt...@stefan-marr.de wrote: Hi: On 15 Jan 2012, at 19:06, Stéphane Ducasse wrote: Stefan why Shift+N is not enough for you? Shift+N? I assume you refer to cmd+n on a Mac, which gives me all senders. No. cmd + shift + n gives you the list of references to a class. Well, senders of #new is not exactly helpful. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 -- Mariano http://marianopeck.wordpress.com -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Styling in Inspector
I added the following method to inspector and styling turned on: shoutAboutToStyle: aPluggableShoutMorphOrView ^ true Should we add it? Maybe you also want to set the class context so that it doesn't highlight variable references as errors? Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] SmallLint
Hi Simon, The correction of some rules can be automated (eg Rule Unnecessary = true or Variable not reference) - add transformation to these rules. Yes, that would be nice. Some rules such as Spelling rules (eg comments Method: Checks for spelling errors in method comments., 7088 problems) are not very interesting and could be removed (or treated differently?) I like them, but if you don't want the spelling rules you don't have to load or run them. One thing to improve here would be the spell checker: Critics only uses a decent spell checker on OS X, where the one from the platform is available through a primitive. On all other platforms a very stupid spell checker based on a word-list is used. Adding an indice of difficulty to correct the rule: - Level of automation for the correction of the rule (automatic, semi-automatic, …). Actually this information is there: rules correct automatically if the rule is a subclass of RBTransformationRule. - Scope of the rule (block, method, class …). Not sure what you mean, but you can scope the rules to any RBEnvironment (see http://www.lukas-renggli.ch/blog/programmatically-run-lint). Other costs could be - cost of applying (may be the rule requires to compute something else, or if a rule has 5 hits, it generates an extra cost to analyze the results) - cost of NOT applying the rule (if it could detect a bug and we don' t apply it ...) There is something like this in RBLintRule#severity. The severity is shown as an icon in OB. Adding a manifest to manage/mark falses positive: - one manifest (a class) by package. - Manifest: exclusion of class/method of the package for rules or for all the rules. - Exclusion of rules for the package. See http://www.lukas-renggli.ch/blog/ignoring-lint-rules. Also many years ago I wrote some infrastructure to run critics rules as part of the tests, what essentially served as a runnable manifest. The code is in http://source.lukas-renggli.ch/essential.html, but it likely needs some fixes to make it work in a recent version of Pharo. One could also think on how to efficiently visualize the results of smallLint ... See for example the SmallLint results of Seaside 3.0 run by Jenkins: http://jenkins.lukas-renggli.ch/job/Seaside%203.0/791/checkstyleResult/. Cheers, Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] SmallLint
Adding an indice of difficulty to correct the rule: - Level of automation for the correction of the rule (automatic, semi-automatic, …). Actually this information is there: rules correct automatically if the rule is a subclass of RBTransformationRule. Ok good to know. Are they linked to a refactoring? The RBTransformationRules are specified as a rewrite rule, so in the end they are an undo-able refactoring change. - Scope of the rule (block, method, class …). Not sure what you mean, but you can scope the rules to any RBEnvironment (see http://www.lukas-renggli.ch/blog/programmatically-run-lint). This is not in that direction but more. This rule may impact method, classes… One idea is can we propose a way to assess the cost of fixing a violated rules. Not easy since some of the rules are trivially fixed but may report a lot of violated places while a rule can be difficult to fix and only get to one place. Still we would like to give some hints to the maintainer. I think the cost is hard to assess for a tool. It is basically zero if a refactoring can be instantiated to fix it, but for many code critics rules there is no such refactoring. A critics rule is merely a suggestion of how the code could possibly be improved. Other costs could be - cost of applying (may be the rule requires to compute something else, or if a rule has 5 hits, it generates an extra cost to analyze the results) - cost of NOT applying the rule (if it could detect a bug and we don' t apply it ...) There is something like this in RBLintRule#severity. The severity is shown as an icon in OB. Ok we should use that. Jenkins also uses it. All Java tools have a severity flag, so I had to add it. Have a look at source of FireBug, it even goes further (don't remember how). Adding a manifest to manage/mark falses positive: - one manifest (a class) by package. - Manifest: exclusion of class/method of the package for rules or for all the rules. - Exclusion of rules for the package. See http://www.lukas-renggli.ch/blog/ignoring-lint-rules. Also many years ago I wrote some infrastructure to run critics rules as part of the tests, what essentially served as a runnable manifest. what was it? How did you manage false positives. What we want is to add a package Manifesto to store false positives. Because we should not use pragma for that because we will have tons of pragmas everywhere. Yes, the pragmas are not really ideal, because most of the time you don't want to see that kind of annotations. What is available in the repository mentioned is an abstract test case with a test for each critics rule. Projects would subclass that test and override a method returning a default environment to run code critics on. Then you had a little DSL where you could enable/disable certain rules. And you could modify the default environment for each rule individually, that is to add/remove classes, class hierarchies, methods, method prefixes, method patterns, etc. It was basically a manifesto (it could also contain project specific rules) in the form of a runnable TestCase. We used this system successfully for the Cmsbox. After careful configuration we had a system with zero code critics failures. And the build system immediately barked if a new failure was introduced; or an expected one was removed. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Smart bracketing annoyance
For the smart bracketing: Either do not load eCompletion, or change the settings in Code browsing eCompletion. For the indention press Ctrl+Shift+L and Ctrl+Shift+R. Lukas On 7 January 2012 09:29, Milan Mimica milan.mim...@gmail.com wrote: I'll just hijack here: I also wouldn't be totally uncool if you could select a block of code an press (shift-)tab to (un)ident it. Basic stuff really. On 7 January 2012 05:32, Ben Coman b...@openinworld.com wrote: I am still coming to terms with the smart bracketing where pressing the open-round-bracket key also produces a close-round-bracket, but I'm working on adapting. One thing that is ultra-annoying and that could be smarter is where for instance, being new to Smalltalk, I have got my round and square brackets mixed up preceding an ifTrue:. So I highlight the open-round-bracket, press the open-square-bracket expecting it to be replaced (like every other system I've dealt with) and surprise* now I've got the original round-bracket surrounded by two new square-brackets. If it instead found the matching close-round-bracket and changed both round-brackets to square-brackets, that would be cool rather than frustrating. The same applies to trying to correct string quotes and comment quotes. I hope that sounds reasonable and it would nice if it could be changed. cheers, Ben *surprise - not good for people new to the software you are trying to impress -- Milan Mimica http://sparklet.sf.net -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Misc. newbie questions
On 6 January 2012 11:20, Peter Hugosson-Miller oldmanl...@gmail.com wrote: On 6 jan 2012, at 06:41, Gerry Weaver ger...@compvia.com wrote: 2. There appear to be some tool choices in the Pharo image. I would like to be able to create a class and it's methods in an editor in one go. I like being able to see all of the class code at once. Is there a way to do this? I just want to be able to type it all in and accept (evaluate?) all at once. This is an interesting question to me personally. After 15 years of working exclusively in Smalltalk I've recently been forced to start programming in Java, where the source code is always (as far as I know) arranged in the way you describe. This organization just emphasizes the dead and compiled nature of Java (and similar languages), compared to the living objects of Smalltalk, where even methods are objects, created by sending messages to other objects. Source code is relegated to being a mere artifact, which can be saved and organized in any way one wishes, and preferably never shows its ugly face to the coder :-p Which of course is no argument why Smalltalk code could not be displayed in a more programmer friendly way as a continuous block of text. There is no technical reason why source ranges in text box couldn't correspond to life method objects. Compared to other languages it is extremely tedious in Smalltalk to get an overview over a project, a package, or even a single class or to navigate between entities. And yes, I really *really* miss a good, object oriented class browser! Eclipse is pretty good, especially with the Java Browsing Perspective. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Refactor class Accessors not working for instvars with leading numeric
The Smalltalk syntax does not allow leading numbers in variable or selectors. Prefix it with an underscore. It is strange that you could add an instance-variable with that name in the first place. Lukas On 6 January 2012 16:34, Ben Coman b...@openinworld.com wrote: For the following accepted class definition (so presumably leading zero is a valid instance variable name), from the menu selecting Refactor class Accessors fails with Error: End of statement list encountered EpcimIdentifiedObject subclass: #EpcimBaseVoltage instanceVariableNames: '0nVoltageLevel' classVariableNames: '' poolDictionaries: '' category: 'IEC61970-Core' If I take away the leading zero on the instance variable it works okay. I can get by with it not working but wondered whether I log a bug report or am I doing something wrong? I do want to keep the leading zero because I am using it to mark the multiplicity of associations (eg see BaseVoltage/Voltage down the bottom of [1]). [1] http://forum.world.st/forward-engineering-UML-models-into-Smalltalk-code-td3729255.html -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] About announcements
No, because the Announcement#handles: takes a class, not an instance. you mean here: deliver: anAnnouncement deliver an announcement to receiver. In case of failure, it will be handled in separate process ^ (self handles: anAnnouncement class ) ifTrue: [ [action cull: anAnnouncement cull: announcer] on: UnhandledError fork: [:ex | ex pass ]] we can simply change the 'anAnnouncement class' to just 'anAnnouncement' so the receiver of #handles: will see an announcement itself not its class. It is probably right thing to do, because then you can do: announcer on: foo do: [... ]. announcer announce: 10. Then foo will receive: foo handles: 10. and in your own #handles: implementation you can do something like: handles: anAnnouncement ^ anAnnouncement isInteger Yes, #handles: should take an instance not a class. And #handles: should be implemented as Announcement class#handles: anAnnouncement ^ anAnnouncement isKindOf: self I guess this is partially my fault, because I called the argument anAnnouncementClass even if I passed in an instance. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] About announcements
If everybody has its own version then we do not improve the infrastructure. Performance issues aside, the current implementation forces me to use a different implementation because Pharo's announcements have a different implementation of selecting the handler (point 7). However, the really weird thing is that Pharo's announcements are now suddenly inconsistent with the Pharo exceptions and how they select the handler. Do you think this is better or worse? you lost me here. why announcements have to be consistent with exceptions? something which is completely orthogonal to them? Exceptions and Announcements used to implement a very similar protocol: see their implementation of X class#handles:, Xon:do:, XSet#handles:, XSet#, etc. Consistency makes frameworks easy to understand and use. it is like saying that apples are inconsistent with oranges. - Apples and oranges are inconsistent the way they are eaten (oranges have to be piled first and come in slices). - Apples and pears are consistent the way they are eaten (even if they taste very different). If that is too abstract replace Apples = Announcements Oranges = change:/update: Pears = Exceptions Lukas aside of that, i added the changeset, so you can now choose whether your announcement subscription is handling announcement or not based on announcement object itself, not its class. see http://code.google.com/p/pharo/issues/detail?id=5145 -- Best regards, Igor Stasenko. -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] glamour and pharo
What I'm NOT saying: Kernel and Tools should be coupled. (If ppl whant kernel+other things, they are welcome to have it... I myself will want it) This coupling is exactly what is happening. How do you propose to build your kernel+other distribution? What coupling you are talking about? Can you give an example? Instead we striving to decouple components of the system and improve infrastructure. If you speaking about announcements, so here the vision: - there are tons of different event driving mechanisms in image and we want to leave only one, replacing all of them with announcements. Will this couple tools to announcements? Of course. Will this add unnecessary coupling between layers? No. Because announcements is inherently serving for decoupling event source(s) from event consumers. THis is not about announcements. I am talking about adding new UI, FileSystem, Refactoring, Compiler, Tools, ... frameworks. Any such addition will increase the coupling in Pharo because the core and external clients will start to slowly adapt these frameworks. This adaptation increases the coupling (to this particular framework) and means that it will be increasingly hard to unload or replace them in the future. Or shorter: What you add today, you cannot easily remove again tomorrow. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] glamour and pharo
To you, the current Pharo image is the Pharo Core and you are unhappy that it is too big (for example because RB is there). The size is the least problem. More annoying is that the code quickly gets out of sync and non-changes are added to the history. Both of these problems are already visible today. Additionally, over time people will change/add/remove features that get integrated without proper review. I just had a look at the announcement framework in Pharo 1.4 today, it is unbelievable how a tiny framework could degrade to a bloated, untested and dead slow pile of mud in just a few years :-( I think your are unfair here. The new features might be untested (current coverage is at 56%), but the changes were meant to provide working weak announcements. And they do work. Nice argument for your students reading this thread: http://memegenerator.net/instance/12779750. But, what do you mean by slow? How did you benchmark it? No, but if you look at the code you will see many extra steps: 1. It tests if a registry is there: Why would that be necessary in an object-oriented implementation? 2. It tests if the registry is empty: Why would that be necessary in an object-oriented implementation? 3. It enters a critical section of a monitor: This is rarely useful and the slowest kind of concurrency control available in Pharo (a Mutex would be enough for what it is used for, and instantiate multiple semaphores and queues), and btw the lazy initialization of the monitor is the prime example of a race condition. 4. It creates a copy of the collection of all the subscriptions: This is rarely useful and wouldn't be necessary if an immutable data structure was used. 5. It iterates over all announcements, it doesn't even try to group announcements of the same kind. 6. It wraps each announcement delivery into a curtailed block. It does that even for those that are never actually announced. 7. It then tests each announcement if it matches, again it doesn't even try to group the announcements of the same kind. Aside, the match test was changed so that it doesn't allow instance-based announcements anymore, breaking some of my code. 8. It then wraps the actual notification into an exception handler. Again, this is rarely useful and should probably rather be something pluggable. 9. It then culls the announcement and announcer into the block. Not sure why the announcer is useful, after all the block was registered with the announcer at some point. So all these 9 steps are not really necessary (or even wanted) in most case. I doubt that any of them makes the code faster. I am glad that the code works for you even if all of this new functionality is untested. And good luck with the race condition :-) There is a point in here. But, as I said, I thought that the point is to produce the core by having jenkins strip away unwanted material. Of course, the other way would be to start from the core as a seed and have jenkins produce the current image. Do you really believe that stripping away unwanted material works? No other open source project in the whole world does it like that, everybody builds distributions on top of a smaller core: Linux, GCC, Gnome, FireFox, ... Even in the supermarket, you typically don't get a vegetable hamper if you just want a some potatoes. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] glamour and pharo
please read this mail until the end before replying :) Done. Moreover, every generic framework included with the core will sooner or later introduce dependencies from random core packages. Why do you say random. Of course people make mistakes and are not perfect. But we will fix it. I am saying random because people (including me) will start to use whatever the auto-completion is offering. And we all know that the proposals of the auto-completion are rather random at times. You can see that in Pharo, Seaside, Pier, Magritte, ... over time packages tend to blend. Whatever you add now, you cannot easily remove tomorrow. You see I read and spent time to answer your kind of mail. Because you are still my friend and because I had a lot of fun with you and I'm sure that you could have fun with us. Thank you. Now this makes me wonder how I should behave if I am not allowed to say why I think that Pharo is on the wrong track? You want me to shut up and fork from Pharo 1.3? I guess this is only way, because with the inclusion of RB into Pharo 1.4 people that want to use the original version and everything that depends on it (maybe this is just me?) are locked out. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] glamour and pharo
and fork from Pharo 1.3? I guess this is only way, because with the inclusion of RB into Pharo 1.4 people that want to use the original version and everything that depends on it (maybe this is just me?) are locked out. Not totally true :). I could merge the code each time you publish a new version but this is tedious. So how do we collaborate? :). First I will update the RB version. I looked at the ConfigurationOfRefactoringEngine today, and I could not figure out how to update it: - There is now a package Refactoring-Pharo-Platform that should be loaded together with Refactoring-Core. - There seems to be some code moved between the packages in Pharo 1.4, so I don't see how the head can be merged with that code. - There are parts for GemStone and Squeak in the configuration, that I don't know how to deal with. You see it works with zinc and zinc is even more central because sometimes I cannot update the system anymore :). Zinc is something else. Zinc is a clean replacement for HTTPSocket. It is backward compatible by providing the old and ugly HTTPSocket interface. The refactoring engine is something entirely new that you think you might want to use in the future for remote images. Now that sounds to me more like a research project that should be done aside, without inflicting on the current development. As discussed previously, I don't think that the refactoring engine provides the right model for this task; but should it turn out otherwise, why not adapt it at that time? Also I don't see why Pharo would want to have remote editing functionality in all images. Shouldn't that better be a completely separate project? This leads me to the question: Did anybody ever sketch an architecture of where Pharo should be heading to? I created a simplified one based on my own understanding of the current proposals: http://bit.ly/vpnAf1 (Google Docs). I think Pharo should concentrate only one the blue squares, eventually only on the dark-blue one. Everything else should be a distribution on top. Kernel developers might want/need to use a distribution on top of the kernel themselves. Although it has been argued in the past that this doesn't work, I don't see a reason why not. In any other open source project (i.e. a Linux kernel hacker might as well use Emacs or Gnome, even if they are not part of the kernel) people work like this, why not in Pharo too? Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] glamour and pharo
The refactoring engine is something entirely new that you think you might want to use in the future for remote images. Now that sounds to me more like a research project that should be done aside, without inflicting on the current development. Now see above this is not research. I cannot publish anything on that. Ok, then be it a separate open-source project that Pharo does not need to depend on. As discussed previously, I don't think that the refactoring engine provides the right model for this task; but should it turn out otherwise, why not adapt it at that time? Also I don't see why Pharo would want to have remote editing functionality in all images. Shouldn't that better be a completely separate project? Lukas we want only one compiler but we should be able to edit its code. RIght now marcus has the old compiler as a fallback and this is annoying. We should be able to run two compilers side by side (this is why Opal should be parametrized by environment (smalltalk) but also object environment (nil true….) so that we can bootstrap it with itself. I don't understand what you write, but I guess it boils down to having namespaces that allows one to load and use different variations of the same code at once. This would also solve my problem with the refactoring engine: Pharo could depend on one version, I could use another one. Seems to me quite a central kind of functionality to make progress. Again to make the analogy with Linux: This seems to be the virtual machines that allow one to easy test and run other kernels aside. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] About announcements
Ok, first of all I did not know who wrote the code. I was just fixing some of my code that suddenly broke and was astonished what the announcer all does when stepping through the announcement procedure with the debugger ... 3. It enters a critical section of a monitor: This is rarely useful and the slowest kind of concurrency control available in Pharo (a Mutex would be enough for what it is used for, and instantiate multiple semaphores and queues), and btw the lazy initialization of the monitor is the prime example of a race condition. agreed here. I would even leave a semaphore. I think it is overlooked by Henrik. It also don't needs a lazy initialization in #protected: , since in #initialize it can just create a ready for use fresh synchronization object. A semaphore might block, because an announcement could register another announcement. So probably the Mutex would be the right thing to use. 4. It creates a copy of the collection of all the subscriptions: This is rarely useful and wouldn't be necessary if an immutable data structure was used. propose better solution how to deal with situation when during handling an announcement, your handler unsubscribing from announcer. Array. Slower for registration, but faster at announcing (the common operation). 5. It iterates over all announcements, it doesn't even try to group announcements of the same kind. it is pointless to group them, and makes no real difference. Because announcer doesn't knows what kinds of announcements will be announcement, and it knows only about subscriptions. Suppose i have a subscription to Announcement. And i announcing AnnouncementA (a subclass of it). Fair enough, probably it doesn't matter. 7. It then tests each announcement if it matches, again it doesn't even try to group the announcements of the same kind. Aside, the match test was changed so that it doesn't allow instance-based announcements anymore, breaking some of my code. what is instance-based announcements? If you have a client with 1000 different possibly dynamically changing properties and you want a way to register for announcements of a single property. The current implementation forces you to create a class per property, previously you could fake a kind of announcements with an instance. you can use any object as a subscription selector, just make sure it understands #handles: message. i.e. No, because the Announcement#handles: takes a class, not an instance. 9. It then culls the announcement and announcer into the block. Not sure why the announcer is useful, after all the block was registered with the announcer at some point. cull there is for passing optional arguments. I didn't complain about #cull:, but about the useless announcer passed in. Now for me you don't need to change the semantics of the Pharo Announcements again. Now for my code I will just use my own implementation that has exactly the behavior and performance characteristics I need. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] glamour and pharo
IMHO, Pharo can never be just what Lukas propose: just a kernel, like linux, allowing different distributions. Esteban, why not? Can you give one technical reason why what Linux does cannot work for Pharo? Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] roadmap
- beside RB and Announcements, are there other things that could be problematic Anything that is forked and changed, and that has existing could become a potential problem: - AST-*: No changes at the moment. - Announcements-*: A big problem, but simple enough to work around. - FileSystem-*: A big problem, the method renaming make it impossible to use it with any code that depends on the official version. - Refactory-*: No big changes at the moment. - SUnit: Some problems in the past. - Shout: Some problems in the past. - ... Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] glamour and pharo
is not that *it can't* is that, as a development platform, Pharo needs to provide kernel+tools, not just kernel. Anyway, I was not arguing against having a small kernel, I was arguing against pharo just doing the kernel. Linux itself can't be distributed just as a kernel, it is distributed with a full set of different tools: GNU/Linux, Ubuntu Linux, etc. (btw... this is one of the arguments Stallman allways says about Linux: it was possible because there was already a lot of tools) And, in that case, just as Linux, we can't just do the kernel, we need to provide development tools... otherwise, people wont use it. I myself wont use it for my commercial applications if I do not have something like OmniBrowser to develop. I totally agree, the Pharo Kernel alone is not very useful for an end-user. However, with the emerging Pharo architecture you can hardly build a different distribution. To use the Linux analogy: You are trying to convince GNU/Linux to rebuild their system on top of a full-fledged Ubuntu distribution. What I'm NOT saying: Kernel and Tools should be coupled. (If ppl whant kernel+other things, they are welcome to have it... I myself will want it) This coupling is exactly what is happening. How do you propose to build your kernel+other distribution? Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] roadmap
- beside RB and Announcements, are there other things that could be problematic Anything that is forked and changed, and that has existing could become a potential problem: - AST-*: No changes at the moment. We plan to change it. I asked camillo to discuss the changes in the mailing-list because we want pinocchio analysis to be applied on Pharo and for that we need some extensions. So what is the process? - Announcements-*: A big problem, but simple enough to work around. - FileSystem-*: A big problem, the method renaming make it impossible to use it with any code that depends on the official version. How can the core of pharo work with FS if FS is not loaded in Pharo? Then my question is: How can anybody use Pharo that does not want to use your changes of AST and FS? Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] About announcements
Now for me you don't need to change the semantics of the Pharo Announcements again. Now for my code I will just use my own implementation that has exactly the behavior and performance characteristics I need. Lukas our state of mind is that we want the infrastructure gets better so we like to change for a better one if this better one is better. Seems that the understanding of what is better/worse and what is progress/regress is rather different among people. If everybody has its own version then we do not improve the infrastructure. Performance issues aside, the current implementation forces me to use a different implementation because Pharo's announcements have a different implementation of selecting the handler (point 7). However, the really weird thing is that Pharo's announcements are now suddenly inconsistent with the Pharo exceptions and how they select the handler. Do you think this is better or worse? Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] seaside and pharo (was: glamour and pharo)
So, before dismissing Seaside, perhaps it would be useful to actually look into it. rofl, made by day Can we turn this into a meme? Definitely, http://memegenerator.net/instance/12756821. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Happy new year..
. I find Pharo 1.2 more stable than 1.3 latest... Me too. But it is not the core which is less stable in 1.3, but the dev tools. Mariano, this is a logic puzzle for you: http://memegenerator.net/instance/12757355 Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] glamour and pharo
But, most people will load exactly the same thing: one set of development tools that should do the basic work nicely. This was the point of the Pharo distribution. And it shipped with OB and it was great. OB was never part of PharoCore, it was part of a distribution (PharoDev) that originally Damien and then other people built on top of PharoCore. For some reasons (not understandable to me) it was decided not to have this official distribution anymore, but people continued to build and use different distributions (see Moose, Seaside, ...). Only OB is rather limited, and apparently, it will not be supported anymore :). So, from this point of view, a browsing infrastructure is relevant for the Pharo distribution. OB is supported in Pharo 1.3. In fact, Colin and I have spent a lot of time during the past months improving OB: laying the ground work for multi-selection/trees, redesigned the rendering platforms (tool builder, polymorph, web, ...; drag drop, resizable panes), , etc. Now, to me it seems that there is a problem with what different people understand by Pharo. And I think it would be good to clarify how we should get to the core image so that Lukas can get peace of mind :) This proposal is as ridiculous as if like Linux would suddenly decide to include KDE or Gnome in the kernel. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] glamour and pharo
To you, the current Pharo image is the Pharo Core and you are unhappy that it is too big (for example because RB is there). The size is the least problem. More annoying is that the code quickly gets out of sync and non-changes are added to the history. Both of these problems are already visible today. Additionally, over time people will change/add/remove features that get integrated without proper review. I just had a look at the announcement framework in Pharo 1.4 today, it is unbelievable how a tiny framework could degrade to a bloated, untested and dead slow pile of mud in just a few years :-( Moreover, every generic framework included with the core will sooner or later introduce dependencies from random core packages. This only makes it harder to have a modular system. And people that want to use another refactoring engine (or another version thereof) are excluded, because existing code depends on the included version. Again look at where the announcements are used and how people work around to use their own implementation. p.s. I am happy that the competition pushes OB to get trees and resizable panes :) OB does not intend to compete with Glamour. OB only aims at a tiny subset of what Glamour tries to solve. Lukas -- Lukas Renggli www.lukas-renggli.ch
[Pharo-project] seaside and pharo (was: glamour and pharo)
a couple of things I would like to enhance (for example, the request ideas from Omnibrowser, or the wizard workflows from Merlin), but it has proved to be quite solid until now. So, before dismissing Glamour, perhaps it would be useful to actually look into it. Cheers, Doru On Dec 31, 2011, at 1:00 PM, Tudor Girba wrote: Hi Stef, You seem to say that it is bad that Glamour provides a good infrastructure that appeals to people. Maybe a better conclusion is that Glamour is something to be considered for the infrastructure of Pharo. Do you think so? I do not think that we can base our infrastructure on something that only one person understand and can modify. You will tell that this is the same for Morphic but this is not true. Stef -- www.tudorgirba.com Beauty is where we see it. -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Where did the Promise go?
I don't think that there was ever such a class in Pharo. Lukas On 31 December 2011 14:18, Stefan Marr smallt...@stefan-marr.de wrote: Hi: Was the Promise class removed from the system for cleaning, and because it was not used? Or was there another reason for not having it in its classic form? Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] glamour and pharo
On 31 December 2011 23:33, Stéphane Ducasse stephane.duca...@inria.fr wrote: I looked at it and I do not like the magic of the block and arguments and the scripting aspects Veronica showed me that she does not use long scripts. Still I do not see how we extend browsers. We discussed that during the PhD meal at bern with lukas and I'm still not convinced. Now if people want to load glamour perfect. Now I do not have any spare cycles to maintain it. My plate is full. For now I would like to have a good way to build and reuse Morphic widgets not to create another layer on top. +1000 Pharo should concentrate on the infrastructure, so that load what they want: Glamour, OmniBrowser, ...; Seaside, Iliad, ...; or whatever the next big thing is. Happy new year, Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Classes referenced in code string
This is the rest of the code: ast := RBParser parseExpression: 'Object new. String new'. ast annotateInClass: UndefinedObject. (ast allChildren select: [ :each | each isVariable and: [ each variableBinding isLiteralBinding ] ]) collect: [ :each | each variableBinding binding value ] -- an OrderedCollection(Object String) #variableBinding returns the object knowing all details about the variables. It is only available after you annotated the AST with #annotateInClass:. Lukas On 30 December 2011 08:56, Lukas Renggli reng...@gmail.com wrote: On 30 December 2011 01:23, Sean P. DeNigris s...@clipperadams.com wrote: Lukas Renggli wrote Can be easily done with RB: You parse it (RBParser parseExpression: aString) and do a semantic analysis (see the tests in AST-Tests-Semantics for examples). Thanks, Lukas! How did I know that you would answer ;-) I got that far, but couldn't figure out what to pass to annotateInClass:. Not calling it, or passing nil both lead to errors. Yes, you need to call it. It tells the AST in what context (to what class self should refer to) it is used. For a workspace expression where self refers to nil you have to pass in UndefinedObject. Lukas -- Lukas Renggli www.lukas-renggli.ch -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Classes referenced in code string
Can be easily done with RB: You parse it (RBParser parseExpression:
aString) and do a semantic analysis (see the tests in AST-Tests-Semantics
for examples).
Lukas
On Thursday, December 29, 2011, Sean P. DeNigris s...@clipperadams.com
wrote:
How would I programmatically find out what classes are referenced in a
string. For example:
'Object new. String new' would return { Object. String }
--
View this message in context:
http://forum.world.st/Classes-referenced-in-code-string-tp4244214p4244214.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
--
Lukas Renggli (mobile)
http://www.lukas-renggli.ch
Re: [Pharo-project] Classes referenced in code string
On 30 December 2011 01:23, Sean P. DeNigris s...@clipperadams.com wrote: Lukas Renggli wrote Can be easily done with RB: You parse it (RBParser parseExpression: aString) and do a semantic analysis (see the tests in AST-Tests-Semantics for examples). Thanks, Lukas! How did I know that you would answer ;-) I got that far, but couldn't figure out what to pass to annotateInClass:. Not calling it, or passing nil both lead to errors. Yes, you need to call it. It tells the AST in what context (to what class self should refer to) it is used. For a workspace expression where self refers to nil you have to pass in UndefinedObject. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Roeltyper
Did you publish the patch? I guess that was fixed a long time ago. At least it does not crash my image, it just produces wrong results. What is wrong? What would be good is to remove the VW compliant classes and layers because like that it should be really simple. It is highly complex, because it does an abstract interpretation of the bytecodes and getting the offsets of the variables right is not trivial. In fact in the past 2 years several people have tried to fix (including me) and didn't get it to work. Indeed, we had to patch it to not crash in Moose. But, still it does not seem to work properly. Maybe you should rather use RBRefactoryTyper? It is slower, because it needs to parse all the involved source code; but it works correctly and uses a similar (even more powerful) inferencing algorithm. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Roeltyper
Indeed, we had to patch it to not crash in Moose. But, still it does not seem to work properly. Maybe you should rather use RBRefactoryTyper? It is slower, because it needs to parse all the involved source code; but it works correctly and uses a similar (even more powerful) inferencing algorithm. This is true that roel only checked within a method (from my memory) so with short method this is difficult to get really good result. RoelTyper and RBRefactoryTyper do essentially the same: For class- and inst-vars they look at all the compiled methods that refer to these variables. RoelType does an abstract byte-code interpretation to figure out the assignments and the messages sent to the variables; RBRefactoryTyper parses the methods and figures out the assignments and messages sent using the AST. Then they both run a very similar algorithm to figure out the most likely kind of object hold in the variables. They do not necessarily report the same classes in the end, because the heuristics are different. Also RBRefactoryTyper goes a step further and tries to figure out type of elements inside collection types. For method arguments and temporaries they both only look at a single method (there are obviously no other references to the temporaries and arguments). Consequently they both deliver bad results for arguments and temporaries. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Roeltyper
Yes when I looked at RB (in 99) I guess that they also used existing instances to try to get more information but mainly for instance variables. I am not aware of such code. RBRefactoryTyper is part of the refactoring engine since I first looked at it around ESUG 2002. It is relatively hidden, and only used by a few refactorings to provide better default suggestions (i.e. extract to component). It is also used in OB to provide a better default class comment template. And in ECompletion for better suggestions since RoelTyper is not useable anymore. I would really like to see more work around practical tools that can help us. I have the work on type inference from francisco garau on my hard-disc. But this is a pity that nobody build on top of that. Never heard of that code. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Roeltyper
Does it actually work? I haven't seen a version that correctly works in recent closure images. Lukas On 26 December 2011 05:18, Sean P. DeNigris s...@clipperadams.com wrote: I added a little blurb w. link to the collaborative book - http://book.pharo-project.org/book/PharoTools/roeltyper/ -- View this message in context: http://forum.world.st/Roeltyper-tp4233847p4233847.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] How to handle Squeak / Pharo differences
but Preferences is removed from Pharo. Which project can I look at to see how to handle common Squeak / Pharo incompatibilities ? OmniBrowser, Seaside, ... they all have platform packages that handle such things. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] How to handle Squeak / Pharo differences
I do not get why Seaside should provide a package to deal with Preferences a la squeak? I imagine that Seaside does not rely on Preferences so. Indeed, Seaside does not deal with Preferences, but the question was about how to deal with differences in general. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] How to handle Squeak / Pharo differences
For Seaside 2.x this is the global variable SeasidePlatformSupport that has to be bound to some implementation (this was a bit hacky). For Seaside 3.x this is the abstract class GRPlatform, and the Pharo implementation is GRPharoPlatform. There are countless *-Pharo packages that add Pharo specific code (mostly to GRPharoPlatform). For OmniBrowser this is the abstract class OBPlatform, and the Pharo implementation in OBPharoPlatform. It redirects some of the preference code. For the UI differences this is the abstract class OBInterface, and the Pharo implementation OBPolymorphInterface. Again the code is in platform specific packages, so you typically won't see the code for other platforms. Lukas On 26 December 2011 11:38, laurent laffont laurent.laff...@gmail.com wrote: On Mon, Dec 26, 2011 at 11:31 AM, Lukas Renggli reng...@gmail.com wrote: I do not get why Seaside should provide a package to deal with Preferences a la squeak? I imagine that Seaside does not rely on Preferences so. Indeed, Seaside does not deal with Preferences, but the question was about how to deal with differences in general. Yes. Lukas, do you have some Seaside / OB class names in mind so I can find faster ? Thanks Laurent Lukas -- Lukas Renggli www.lukas-renggli.ch -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Better Gofer error messages
What it is now is unusable, sorry. To prepare a right script is a big pain. Specially because there are nowhere rules how packages are resolved by a name. It will help if in exception at least a link to the some wiki with rules would be shown. I assume you didn't even bother to check the class comment of Gofer, because if you did you would have found a verbatim copy of the wiki article. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Keymapping OB conflict (was Re: Chasing Browsers)
- then that OB can be loaded on top of Pharo. Remember we are not against OB we just do not have the knowledge to maintain it. So if lukas gets OB working for 1.4 beta then we will probably include in Pharo. Now if OB is working for 1.4 only three months after 1.4 is released then we will not include it. Yes please, do not wait for me. Just to repeat myself: With Pharo 1.4 having uncountable changes in core parts of the system and with the system including more and more forked and increasingly incompatible versions of packages (AST, RB, FS, Shout, Regex, ...) I am unwilling to go through the same pain as with Pharo 1.3 again. In the current state, I don't see any of the code I am involved with (including Seaside, Magritte, Pier, OB, PetitParser, ...) to move forward. I suspect that moving to another development platform soon causes less pain than to move to adopt the next Pharo :-( Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Keymapping OB conflict (was Re: Chasing Browsers)
This is important for us to know that and this is a really nice stab in our back and this will kill a lot of the effort we build over the years. I don't understand why you think this is a stab into your back? I have repeated the same concerns over and over again. Now how can we make progress if we do not change Pharo? Again, we already discussed this many times. I think Pharo is totally off the track: Pharo should concentrate on getting a stable core and enabling distributions on top, not on integrating as much new things as possible. May be a dead pharo is better for you. A dead Pharo is not my goal. I need a minimal Pharo with an absolutely trusted and stable core; a system where I can load all my code; a system that does not force me to use things I don't want to use. @Lukas: please, could you point out what are the expected problems? For example, all PetitParser-Tests are green out of the box in the latest 1.4. Nice, maybe the others also just work? OB does not work though because Polymorph changed (and the debugger doesn't even open in the UI thread anymore either, so it is not possible to figure out the problem); and because it expects a different version of RB. You were against changing RB, so how can we do remote tooling? I was against chaining RB, because the proposed changes undermined design decisions in RB. In general, it feels extremely strange to me if people change code (or even class comments) without understanding the code. Also, for that matter, I don't see how you want to use RB for remote tooling? If you remember, I pointed out an interview a while ago with John where they discuss why remote tooling wouldn't work without rewriting most parts. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] RB AST Rewriter to eliminate/consoliate temporary variables?
Hi Stefan, I think there is a lint rule that does that: TempNotRead ... I don't have an image at hand, but I can check tonight if you haven't found it until then. Lukas On 9 December 2011 16:29, Stefan Marr ph...@stefan-marr.de wrote: Hi all, Hi Lukas: Do you know if anyone ever implemented a rewriter for the RB AST that reduces the amount of temporary variables if possible? I have a naive rewriting step that creates too many temps, but some of them are not strictly necessary. However, currently, I run into 'Cannot compile -- stack including temps is too deep' which is, well, ehm, not so nice. In case anyone has something in that direction, I would be interested. Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] RB AST Rewriter to eliminate/consoliate temporary variables?
I basically want to be able to automatically reduce the number of temps for the following example to one: | t1 t2 | t1 := o1 foo. o2 bar: t1. o3 bar: t1. t2 := o1 foo. o2 bar: t2. o3 bar: t2. Of course it is slightly more complex than that, because the usage of the temps is not just in a sequence, but can be also in blocks, or nested expressions. But in this simple example, I could remove t2 and use t1 instead. No, o1 foo, o2 bar: t1, o3 bar: t1 could have side-effects that influence what o1 foo returns. No tool on the world (without additional knowledge) can safely replace t2 with t1. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] RB AST Rewriter to eliminate/consoliate temporary variables?
But in this simple example, I could remove t2 and use t1 instead. No, o1 foo, o2 bar: t1, o3 bar: t1 could have side-effects that influence what o1 foo returns. No tool on the world (without additional knowledge) can safely replace t2 with t1. It is about the slot, not about the value. This is a perfectly legal transformation: | t1 | t1 := o1 foo. o2 bar: t1. o3 bar: t1. t1 := o1 foo. o2 bar: t1. o3 bar: t1. That is the same what register allocators do. t1, as a slot, is not going to be read anymore, thus, the slot can be used to hold another temporary value. Luckily Smalltalk is not a register machine. Even if your example looks perfectly linear, the order in which the statements are executed is pretty much unpredictable (think of exceptions, continuations, reflection, ...). Well, anyway, I just hope that I can work around the frame size limitations when I encounter them in real code. The NewCompiler had a visitor that would overflow excess literals into arrays. You could theoretically do the same for excess temps. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Keymapping OB conflict (was Re: Chasing Browsers)
Ok, then it must be something else. I don't know why this Keymapping thing, but it is unlikely to work with OB if it was not written for OB. As I said, OB managed its keybindings itself. Lukas On 5 December 2011 03:51, Sean P. DeNigris s...@clipperadams.com wrote: Lukas Renggli wrote OB. This means, if you select the method and press Cmd+n it should Bummer, Cmd-n with a method name selected in OB system browser still brings up the non-chasing senders browser. -- View this message in context: http://forum.world.st/Chasing-Browsers-tp4102608p4159064.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Chasing Browsers
Maybe you use the wrong browser? AFAIK, only OB implements it. Lukas On 4 December 2011 18:08, Sean P. DeNigris s...@clipperadams.com wrote: Bump. Anyone? Bueller? -- View this message in context: http://forum.world.st/Chasing-Browsers-tp4102608p4157383.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Keymapping OB conflict (was Re: Chasing Browsers)
Maybe you use the wrong browser? AFAIK, only OB implements it. Ahh, thank you Lukas. It seems like a bug in Keymapping. What do you think, Guillermo? Keymapping? I don't think that would work with OB that has its own keymapping. The problem you observe is a long standing bug: if you don't have a text selection key presses are handled by Pharo not by OB. This means, if you select the method and press Cmd+n it should work. Lukas The situation: In 1.2.2, I get anOBSendersBrowser. However in 1.3 rc, from a method definition in OB: - if I choose Senders from the menu I get anOBSendersBrowser - but if I hit Cmd-n, I get a FlatMessageListBrowser. The call stack: - without key mapping: OBTextMorphkeyStroke: OBTextMorph(TextMorph)handleKeystroke: KeyboardEventsentTo: OBTextMorph(Morph)handleEvent: OBTextMorph(Morph)handleFocusEvent: [ActiveHand := self. ActiveEvent := anEvent. result := focusHolder handleFocusEvent: (anEvent transformedBy: (focusHolder transformedFrom: self))] in HandMorphsendFocusEvent:to:clear: - with Keymapping: SmalltalkEditorsendersOfIt SmalltalkEditorsendersOfIt: [editor sendersOfIt: event] in [:editor :morph :event | morph handleKeymappingInteraction: [editor sendersOfIt: event] fromKeyboardEvent: event] in KMEditorsDefaultSettings classbuildSmalltalkEditorKeymappingsOn: SmalltalkEditor(TextEditor)handleKeystrokeAction: SmalltalkEditor(TextEditor)handleEditionAction:fromKeyboardEvent: [self editor handleEditionAction: aBlockInteraction fromKeyboardEvent: anEvent] in OBTextMorph(TextMorph)handleKeymappingInteraction:fromKeyboardEvent: OBTextMorph(TextMorph)handleInteraction: OBTextMorph(TextMorphForEditView)handleInteraction: OBTextMorph(TextMorph)handleKeymappingInteraction:fromKeyboardEvent: [:editor :morph :event | morph handleKeymappingInteraction: [editor sendersOfIt: event] fromKeyboardEvent: event] in KMEditorsDefaultSettings classbuildSmalltalkEditorKeymappingsOn: -- View this message in context: http://forum.world.st/Chasing-Browsers-tp4102608p4157598.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] VM Exit Value
Not nice, but works reasonably well. The invoking script listens to Pharo generating some output file. Have a look at builder.sh, it does that. Lukas On Friday, 25 November 2011, Sven Van Caekenberghe s...@beta9.be wrote: Hi, For scripting purposes, I would like to use/control the VM exit status/value (on Linux). There is SmalltalkImage#snapshot:andQuit: but there is nothing there that indicates that one can set the process exit status. Is there a way to do that ? Has anyone a good idea on how the CogVM could communicate back to its invoking script whether is ran OK or not ? Thx, Sven -- Lukas Renggli (mobile) http://www.lukas-renggli.ch
Re: [Pharo-project] scripting a package backup
On Monday, 21 November 2011, jannik.laval jannik.la...@gmail.com wrote: Hi Lukas, What I need is the information stored in the Monticello objects (I do not know which one for now). I would like to do something like that: === Gofer new url: (MCSomething new: myPackage) projectUrl; version: currentVersion; fetch Gofer new directory: myDirectory; package: myPackage; push === Do you know how to get the Monticello distant url of a package ? and to get the current version ? The package does not know its URL, but the working copy (MCWorkingCopy allManagers) has a repository group containing all the associated repositories. I saw that the Monticello GUI does it. Then look in that code :-) Lukas Thank you Jannik On Nov 18, 2011, at 22:07 , Lukas Renggli wrote: On 18 November 2011 21:40, jannik.laval jannik.la...@gmail.com wrote: My point is that I do not want to know the remote repository. I just want to copy my current package on a local repository. When you write squeaksource: 'remote', you suppose that your package is on squeaksource in the project named remote. That is that information that I do not want to give. Everything that is not your package cache is remote. It can also be a directory on your HD, a GOODS database, or whatever ... I need the process that creates the mcz file, to copy it on a repository. I do not get it. Maybe you want to give more context? Jannik On Nov 18, 2011, at 18:37 , Lukas Renggli wrote: On 18 November 2011 16:11, jannik.laval jannik.la...@gmail.com wrote: Yes, that is my problem ! I want to export packages in a repository outside the package cache and with an empty package cache. The problem to pull the version first, is to know the url of the version. I don't get your problem! Gofer new squeaksource: 'remote'; version: 'Foo-123'; or package: 'Foo' if you want all version fetch Gofer new squeaksource: 'backup'; version: 'Foo-123'; push Jannik On Nov 18, 2011, at 16:03 , Lukas Renggli wrote: It is all relative to your package cache, so maybe you have to pull the versions first? On 18 November 2011 10:53, jannik.laval jannik.la...@gmail.com wrote: Hi Lukas, I tried: === RPackageOrganizer packageInfoNames do:[:e | Gofer new directory: '/Users/janniklaval/Desktop/MCPackages'; package: e; push. ] === but if the package was not modified, it does not copy the source files. Jannik On Nov 18, 2011, at 10:38 , Lukas Renggli wrote: It would be trivial with Gofer: Gofer new squeaksource: 'backupproject'; package: 'P1'; package: 'P2'; package: 'P3'; push Now of course you can find your script a working script in the class GoferPush. Lukas On 18 November 2011 10:03, jannik.laval jannik.la...@gmail.com wrote: Hi Pharoers, I would like to backup my packages in a repository with a script. I have one constraint: I need to use Monticello (eg, not gofer or metacello). And I do not want to have a version incrementation. --- Jannik Laval -- Lukas Renggli (mobile) http://www.lukas-renggli.ch
[Pharo-project] Fwd: [squeak-dev] OmniBrowser and ToolBuilder
FYI: The mail of Colin Putney to the Squeak mailing list regarding the future of OmniBrowser. For Pharo there are also some changes upcoming: The latest GUI takes better advantage of the standard Polymorph widgets and brings resizable column and faster updates. Lukas -- Forwarded message -- From: Colin Putney co...@wiresong.com Date: 20 November 2011 09:56 Subject: [squeak-dev] OmniBrowser and ToolBuilder To: Squeak-Dev squeak-...@lists.squeakfoundation.org Hi folks, Lately I've been working with Lukas Renggli on a new version of OmniBrowser. The main focus has been on cleaning up and isolating platform dependencies so that we can have a single version that works well on both Squeak and Pharo, while fitting comfortably into each platform's idioms. That part of it has been quite well. For proper integration with Squeak, I've been trying to get OB building its interface using ToolBuilder. It *mostly* works, but there are some areas where ToolBuilder doesn't provide the functionality that OmniBrowser needs. I had planned to extend ToolBuilder a bit with the additional functionality that OB needs, but that turns out to be more work than I anticipated, and I wasn't able to get it done before the 4.3 feature freeze. So, given the constraint of working with the Squeak 4.3 feature set, I'm not quite sure how to proceed. Here are some of the options: 1) Abandon ToolBuilder and just deal with Morphic directly. This is what OB has historically done, and I'd just be updating the old Morphic code to fit better into modern Squeak conventions. There's no longer any need to have this code work on Pharo, since Lukas is now using a separate Polymorph-specific widget package on Pharo. 2) Use ToolBuilder where possible, but customize its output. This misses the point of ToolBuilder, since it means OB won't be able to work with MVC, but at least it reduces the chance that OB will get left behind if someone adds a feature to ToolBuilder. It is a bit of worst of both worlds situation. 3) Use ToolBuilder, and just accept that not all the features of OB will be available until they get added to ToolBuilder. I'm not sure how much graceful degradation I can acheive, but it might not be too bad, and it'll give us (me) motivation to improve ToolBuilder for Squeak 4.4. 4) Have the OB installation process patch the base image to add the needed functionality. That would be the cleanest in terms of the OB code, but has the potential to break other packages that users might want to load. I'd really like to make this next release a solid toolset for Squeak, and fix a lot of the little annoyances that cause Squeakers to avoid it. Lukas' refactoring stuff is really excellent, better than the VisualWorks refactoring browser IMHO, and I want to make it palatable to more people in the Squeak community. I'm leaning towards option #1, because I suspect it's the mostly likely to achieve that, but I thought I'd put it out there and ask the community for advice. So, how important is ToolBuilder? What options am I missing? Cheers, Colin -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] #ifCurtailed:
They both behave the same way in that regard. The argument block is always executed in the owning process, unless an outside process is terminating the process. In this case it is the outside process that unwinds the stack and evaluates the unwind blocks. A long standing bug in my opinion. Lukas On 20 November 2011 15:19, Philippe Marschall kus...@gmx.net wrote: Hi Am I right that the argument to #ifCurtailed: is run in a different process (like #ensure: in an exception case)? Cheers Philippe -- Lukas Renggli www.lukas-renggli.ch
[Pharo-project] Zinc Post requests
Hi Sven, Does #requestBodyFor: in the Zinc server adaptor for Seaside work? Instead of a String I keep on getting strange things back :-) Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Zinc Post requests
Given the current implementation: requestBodyFor: aZincRequest ^ aZincRequest entity you get a ZnEntity subclass back, not a String which WARequest#setBody: seems to expect. As you certainly known, many different kinds of things could be uploaded in a POST, depending on the mime type, some of the important ones are in the subclasses of ZnEntity. I don't think a general conversion to String is possible, unless the idea is that that String should contain the byte representation of what got posted. Seaside expects a string containing the byte representation of what got posted. The #contents method does try to return something useful (sometimes higher level Smalltalk objects). BTW, what is the difference between #requestBodyFor: and #requestFieldsFor: ? Have a look at the Kom adaptor: requestFieldsFor: aNativeRequest | fields | fields := WARequestFields new. aNativeRequest isPostRequest ifTrue: [ self postFieldsOf: aNativeRequest into: fields ]. ^ fields requestBodyFor: aNativeRequest ^ aNativeRequest rawRequestContents Lukas
Re: [Pharo-project] #ifCurtailed:
http://code.google.com/p/pharo/issues/detail?id=5003 On 20 November 2011 17:42, Stéphane Ducasse stephane.duca...@inria.fr wrote: lukas can you open a bug entry? because we should fix this kind of problem. I will discuss it with igor. STef On Nov 20, 2011, at 3:52 PM, Lukas Renggli wrote: They both behave the same way in that regard. The argument block is always executed in the owning process, unless an outside process is terminating the process. In this case it is the outside process that unwinds the stack and evaluates the unwind blocks. A long standing bug in my opinion. Lukas On 20 November 2011 15:19, Philippe Marschall kus...@gmx.net wrote: Hi Am I right that the argument to #ifCurtailed: is run in a different process (like #ensure: in an exception case)? Cheers Philippe -- Lukas Renggli www.lukas-renggli.ch -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Zinc Post requests
On 20 November 2011 22:07, Sven Van Caekenberghe s...@beta9.be wrote: Well I guess this would then do the trick: requestBodyFor: aZincRequest ^ String streamContents: [ :stream | aZincRequest entity writeOn: (ZnBivalentWriteStream on: stream) ] but it hurts: at this point Zn has already parsed/interpreted the entity from bytes and the above code reencodes it again to bytes. That is why I asked if this is needed in all cases, I guess the body will not be used later on if it is either application/x-www-form-urlencoded or multipart/form-data (since these are handled in #requestFieldsFor:). If that is true, a faster fallback based on #contents should be possible (but with some ugly tests). Also a guard testing for entity #isEmpty and non-POST requests will probably be more efficient. Should I try to write a version and commit it ? Yes please, because the current Zinc does not work otherwise for POST requests. I understand the current behavior of Seaside is not ideal and it is cool that Zinc is more powerful than what Seaside expects, but then we have to find a way to expose that in compatible way. Lukas Sven On 20 Nov 2011, at 20:35, Lukas Renggli wrote: Given the current implementation: requestBodyFor: aZincRequest ^ aZincRequest entity you get a ZnEntity subclass back, not a String which WARequest#setBody: seems to expect. As you certainly known, many different kinds of things could be uploaded in a POST, depending on the mime type, some of the important ones are in the subclasses of ZnEntity. I don't think a general conversion to String is possible, unless the idea is that that String should contain the byte representation of what got posted. Seaside expects a string containing the byte representation of what got posted. The #contents method does try to return something useful (sometimes higher level Smalltalk objects). BTW, what is the difference between #requestBodyFor: and #requestFieldsFor: ? Have a look at the Kom adaptor: requestFieldsFor: aNativeRequest | fields | fields := WARequestFields new. aNativeRequest isPostRequest ifTrue: [ self postFieldsOf: aNativeRequest into: fields ]. ^ fields requestBodyFor: aNativeRequest ^ aNativeRequest rawRequestContents Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] how to get a string read stream from filesystem
As I just wrote a few days ago, you must use #fileStreamDo: or #fileStreamWriteable:do: to get the traditional system stream that supports ascii/binary and various convertors. The streams built into FileSystem are minimal ANSI streams. They are supposed to be wrapped by something more powerful. I was told that Xtreams works well with FileSystem. Maybe Nile could be made to work as well? Lukas On 19 November 2011 17:03, Stéphane Ducasse stephane.duca...@inria.fr wrote: Doru FS should be usable so if you have suggestions and code please send them. Stef Hi, Thanks. I know that the ByteArray is the data structure, but I would like to get a stream that decodes the information and lets me traverse characters, rather than bytes. By retrieving aReference readStream contents asString I first get all the ByteArray in memory, and then create another string from it also in memory. If my file is large, this is not a feasible solution. Like Norbert said, I would like to get some support to have a converter in the stream. For example, outside of Filesystem, we can do something like: FileStream readOnlyFileNamed: 'aFileName'. stream converter: TextConverter default. So, I guess, the only way right now is to not use the FSStream, but to get from an FSReference to the FileStream. Do, we want to bring the FileStream closer to FileSystem? Cheers, Doru On 18 Nov 2011, at 07:41, Max Leske wrote: Hi Doru The last time I used FS that was the way to do it. Maybe what you want could be accomplished by adding convenience methods to FSReadStream like #stringContents or something. Anyway, I agree with Norbert that a ByteArray is really the data structure that you should expect to get from a file. Cheers, Max On 17.11.2011, at 22:01, Tudor Girba wrote: Hi, I am using Filesystem, and I would like to get a read stream that provides a string instead of bytes. If I do aReference readStream, I get a FSReadStream which is a byte stream. To get to the string, I now do the ugly: aReference readStream contents asString Is there a cleverer way? Cheers, Doru -- www.tudorgirba.com What we can governs what we wish. -- www.tudorgirba.com Things happen when they happen, not when you talk about them happening. -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] scripting a package backup
It would be trivial with Gofer: Gofer new squeaksource: 'backupproject'; package: 'P1'; package: 'P2'; package: 'P3'; push Now of course you can find your script a working script in the class GoferPush. Lukas On 18 November 2011 10:03, jannik.laval jannik.la...@gmail.com wrote: Hi Pharoers, I would like to backup my packages in a repository with a script. I have one constraint: I need to use Monticello (eg, not gofer or metacello). And I do not want to have a version incrementation. Does someone have any script or any way to do that ? Cheers, Jannik -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] scripting a package backup
It is all relative to your package cache, so maybe you have to pull the versions first? On 18 November 2011 10:53, jannik.laval jannik.la...@gmail.com wrote: Hi Lukas, I tried: === RPackageOrganizer packageInfoNames do:[:e | Gofer new directory: '/Users/janniklaval/Desktop/MCPackages'; package: e; push. ] === but if the package was not modified, it does not copy the source files. Jannik On Nov 18, 2011, at 10:38 , Lukas Renggli wrote: It would be trivial with Gofer: Gofer new squeaksource: 'backupproject'; package: 'P1'; package: 'P2'; package: 'P3'; push Now of course you can find your script a working script in the class GoferPush. Lukas On 18 November 2011 10:03, jannik.laval jannik.la...@gmail.com wrote: Hi Pharoers, I would like to backup my packages in a repository with a script. I have one constraint: I need to use Monticello (eg, not gofer or metacello). And I do not want to have a version incrementation. Does someone have any script or any way to do that ? Cheers, Jannik -- Lukas Renggli www.lukas-renggli.ch --- Jannik Laval -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] scripting a package backup
On 18 November 2011 16:11, jannik.laval jannik.la...@gmail.com wrote: Yes, that is my problem ! I want to export packages in a repository outside the package cache and with an empty package cache. The problem to pull the version first, is to know the url of the version. I don't get your problem! Gofer new squeaksource: 'remote'; version: 'Foo-123'; or package: 'Foo' if you want all version fetch Gofer new squeaksource: 'backup'; version: 'Foo-123'; push Jannik On Nov 18, 2011, at 16:03 , Lukas Renggli wrote: It is all relative to your package cache, so maybe you have to pull the versions first? On 18 November 2011 10:53, jannik.laval jannik.la...@gmail.com wrote: Hi Lukas, I tried: === RPackageOrganizer packageInfoNames do:[:e | Gofer new directory: '/Users/janniklaval/Desktop/MCPackages'; package: e; push. ] === but if the package was not modified, it does not copy the source files. Jannik On Nov 18, 2011, at 10:38 , Lukas Renggli wrote: It would be trivial with Gofer: Gofer new squeaksource: 'backupproject'; package: 'P1'; package: 'P2'; package: 'P3'; push Now of course you can find your script a working script in the class GoferPush. Lukas On 18 November 2011 10:03, jannik.laval jannik.la...@gmail.com wrote: Hi Pharoers, I would like to backup my packages in a repository with a script. I have one constraint: I need to use Monticello (eg, not gofer or metacello). And I do not want to have a version incrementation. Does someone have any script or any way to do that ? Cheers, Jannik -- Lukas Renggli www.lukas-renggli.ch --- Jannik Laval -- Lukas Renggli www.lukas-renggli.ch --- Jannik Laval -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] scripting a package backup
On 18 November 2011 21:40, jannik.laval jannik.la...@gmail.com wrote: My point is that I do not want to know the remote repository. I just want to copy my current package on a local repository. When you write squeaksource: 'remote', you suppose that your package is on squeaksource in the project named remote. That is that information that I do not want to give. Everything that is not your package cache is remote. It can also be a directory on your HD, a GOODS database, or whatever ... I need the process that creates the mcz file, to copy it on a repository. I do not get it. Maybe you want to give more context? Jannik On Nov 18, 2011, at 18:37 , Lukas Renggli wrote: On 18 November 2011 16:11, jannik.laval jannik.la...@gmail.com wrote: Yes, that is my problem ! I want to export packages in a repository outside the package cache and with an empty package cache. The problem to pull the version first, is to know the url of the version. I don't get your problem! Gofer new squeaksource: 'remote'; version: 'Foo-123'; or package: 'Foo' if you want all version fetch Gofer new squeaksource: 'backup'; version: 'Foo-123'; push Jannik On Nov 18, 2011, at 16:03 , Lukas Renggli wrote: It is all relative to your package cache, so maybe you have to pull the versions first? On 18 November 2011 10:53, jannik.laval jannik.la...@gmail.com wrote: Hi Lukas, I tried: === RPackageOrganizer packageInfoNames do:[:e | Gofer new directory: '/Users/janniklaval/Desktop/MCPackages'; package: e; push. ] === but if the package was not modified, it does not copy the source files. Jannik On Nov 18, 2011, at 10:38 , Lukas Renggli wrote: It would be trivial with Gofer: Gofer new squeaksource: 'backupproject'; package: 'P1'; package: 'P2'; package: 'P3'; push Now of course you can find your script a working script in the class GoferPush. Lukas On 18 November 2011 10:03, jannik.laval jannik.la...@gmail.com wrote: Hi Pharoers, I would like to backup my packages in a repository with a script. I have one constraint: I need to use Monticello (eg, not gofer or metacello). And I do not want to have a version incrementation. Does someone have any script or any way to do that ? Cheers, Jannik -- Lukas Renggli www.lukas-renggli.ch --- Jannik Laval -- Lukas Renggli www.lukas-renggli.ch --- Jannik Laval -- Lukas Renggli www.lukas-renggli.ch --- Jannik Laval -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Status of ToolBuilder
I was kind of surprised that ToolBuilder is still part of Pharo. where? Because we removed it. It is contained in the Polymorph packages in Pharo 1.3, but it missing some and has additional other features compared to the version in Squeak. I was asking because OmniBrowser in Squeak is now using ToolBuilder, the code works with a few changes in Pharo 1.3 too. Are there any users? Are there any plans to update it to match the version of Squeak? Is it encouraged to build UIs with ToolBuilder? no :) We were brainstorming on valueHolder, Spec and UIBuilder a la VW with Benjamin and we got the conclusions: Specs are cool because the same application Model can propose multiple spec That has nothing to do with specs though, there are many other ways of how multiple views can work with or provided by the same model. In my experience specs often lack the necessary dynamics to build useful UIs. So a lot of glue code is necessary to assemble the different parts. In the end I find it more convenient to just use the glue code (like in Seaside or ToolBuilder). valueHolder are the building brick to be able to reuse the application model UI logic (and not just the UI widgets). I do not understand that point. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Status of ToolBuilder
where? Because we removed it. It is contained in the Polymorph packages in Pharo 1.3, but it missing some and has additional other features compared to the version in Squeak. I was asking because OmniBrowser in Squeak is now using ToolBuilder, the code works with a few changes in Pharo 1.3 too. Does Toolbuilder make sense? To me it looked like yet another compatibility layer that does not bring anything (other than forcing anyone to use something that has to be compabtible to MVC). It is quite powerful given that it can run OmniBrowser. And the extra layer makes UI building trivially testable. This is not possible when directly using Morphs. For Pharo I will rewrite the OB UI builder to directly generate an optimized Polymorph GUI. This buys more us more flexibility. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Status of ToolBuilder
Does Toolbuilder make sense? To me it looked like yet another compatibility layer that does not bring anything (other than forcing anyone to use something that has to be compabtible to MVC). It is quite powerful given that it can run OmniBrowser. Of course Omnibrowser makes it easy by not allowing anything else than what is in MVC (e.g, Trees). For sake of correctness: ToolBuilder supports trees since at least Squeak 3.9, but probably earlier. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] how should Pier file structures be serialized with Fuel?
Just out of curiosity: Why are PUSecurity linked to too many other objects? Is there a bug leaking memory? Lukas On Thursday, 17 November 2011, Martin Dias tinchod...@gmail.com wrote: Hello! On Thu, Nov 17, 2011 at 1:56 AM, Yanni Chiu ya...@rogers.com wrote: An earlier version of Fuel did not having the substitution feature. So, I had custom mapping code to pre-process the structures before passing to Fuel for serialization, and to post-process the deserialized structures. The main purpose of the code was to nil out the PUSecurity objects, because they were linked to too many other Pier objects. I'm now eliminating the custom mapping code by using Fuel substitution. The PRFile object was handled by saving the file contents in an instance variable of the mapping object. I've eliminated the custom mapping object. Now, how should the file contents be saved/restored, using the substitution feature? I'm thinking of substituting a proxy object, which somehow becomes a PRFile after deserialization. you can implement : YourPRFileProxy fuelAfterMaterialization self become: self proxiedPRFile Anyway, in next version would be nice to provide a faster way of doing this, without become. Any other suggestions? -- Lukas Renggli www.lukas-renggli.ch
[Pharo-project] Status of ToolBuilder
I was kind of surprised that ToolBuilder is still part of Pharo. Are there any users? Are there any plans to update it to match the version of Squeak? Is it encouraged to build UIs with ToolBuilder? Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] FS and binary files
Use #fileStreamDo: or #fileStreamWritable:do: Lukas On 12 November 2011 13:19, Johannes Rasche johannesras...@mac.com wrote: Hi Sean, thanks for your effort and advice, but it didn't resolve my problem: try to open an image file with PNGReadWriter on: xxx.png Lukas wrote: In Colin's code you had to use the third supported stream type: not #readStream and not #writeStream (that are minimal ANSI compatible streams), but a third kind that I forgot the name of (it would return a RBBinaryReadWriteStream that works with most existing code). Johannes Am 11.11.11 16:55, schrieb Sean P. DeNigris: Johannes Rasche wrote: as FS appeared, I had the impression, that this would be the long awaited replacement of FileDirectory, but it doesn't seem so, because it's not part of the official Pharo up to now (1.3), I couldn't wait, so I loaded it in my 1.3-rc image and have been happily using it problem free for 1.5 weeks... Gofer new squeaksource: 'fs'; package: 'ConfigurationOfFilesystem'; load. (Smalltalk at: #ConfigurationOfFilesystem) load. Since Pharo's FS fork is being worked on in 1.4, I may have to port my code slightly for 1.4, but I couldn't go on any longer with FileDirectory, it hurt too much ;-) -- View this message in context: http://forum.world.st/FS-and-binary-files-tp4019963p4031734.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] FS and binary files
I thought it was adopted as part of Pharo 1.4? Or maybe it is just used as part of Coral? No clue ... Lukas On 11 November 2011 08:09, Johannes Rasche johannesras...@mac.com wrote: Thx Lukas, I'll try it ... anyway I'm wondering about that - as FS appeared, I had the impression, that this would be the long awaited replacement of FileDirectory, but it doesn't seem so, because it's not part of the official Pharo up to now (1.3), or is there another alternative to FileDirectory I've overseen? and what do you mean by Pharo forked the original implementation? up to 1.3 I cannot see FS Johannes Am 10.11.11 18:06, schrieb Lukas Renggli: Not really, Pharo forked the original implementation. In Colin's code you had to use the third supported stream type: not #readStream and not #writeStream (that are minimal ANSI compatible streams), but a third kind that I forgot the name of (it would return a RBBinaryReadWriteStream that works with most existing code). Lukas On 10 November 2011 16:25, Johannes Rasche johannesras...@mac.com wrote: Hi Lukas, you may not have realized the message below. I assume you might be the person who coud answer my question Cheers Johannes Original-Nachricht Betreff: [Pharo-project] FS and binary files Datum: Wed, 09 Nov 2011 15:36:16 +0100 Von: Johannes Rasche johannesras...@mac.com johannesras...@mac.com Antwort an: Pharo-project@lists.gforge.inria.fr An: pharo-project@lists.gforge.inria.fr Hi folks, I just started to using FS instead of FileDirectory. On readStream sent to FSReference a FSAnsiiStream turns out, which is not suitable for reading images ( for instance with PNGReadWriter). What did I wrong? Johannes -- Lukas Renggli www.lukas-renggli.ch -- Johannes Rasche *Hagelberger Str. 56 10965 Berlin mail johannesras...@mac.com mobile +49 1577 175 04 75* -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] How to get the list of packages of a repository?
Simpler: (Gofer new disablePackageCache; squeaksource: 'Seaside30'; allResolved) collect: [ :each | each packageName ] as: Set Lukas On 7 November 2011 21:21, jannik.laval jannik.la...@gmail.com wrote: Hi Mariano, You can have all packages in a repository with: repository := MCHttpRepository location: httpUrl user: '' password: '' repository allVersionNames Then you have to select all the last version of each package. A method from Moose that have this behavior: === lastVersionOf: projectName | versions | versions := self fileNames select: [ :f | f beginsWith: projectName , '-' ]. ^ (versions asSortedCollection: [ :v1 :v2 | (v1 copyFrom: (v1 indexOf: $.) + 1 to: (v1 lastIndexOf: $.)) asInteger (v2 copyFrom: (v2 indexOf: $.) + 1 to: (v2 lastIndexOf: $.)) asInteger ]) last === Cheers, Jannik On Nov 7, 2011, at 17:58 , Mariano Martinez Peck wrote: Hi guys. Is there a way to get a list of packages or packages names of a squeaksource repo? For example, I would love to do: Gofer it squeaksource: 'xxx'; allPackages. is that possible? Thanks -- Mariano http://marianopeck.wordpress.com --- Jannik Laval -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] How to get the list of packages of a repository?
Wouldn't make sense to have that code in a #allPackagesNames ? It would be kind of strange, because typically on a Gofer instance you need to specify the packages you want to deal with. Lukas Thanks! On Mon, Nov 7, 2011 at 6:02 PM, Lukas Renggli reng...@gmail.com wrote: Simpler: (Gofer new disablePackageCache; squeaksource: 'Seaside30'; allResolved) collect: [ :each | each packageName ] as: Set Lukas On 7 November 2011 21:21, jannik.laval jannik.la...@gmail.com wrote: Hi Mariano, You can have all packages in a repository with: repository := MCHttpRepository location: httpUrl user: '' password: '' repository allVersionNames Then you have to select all the last version of each package. A method from Moose that have this behavior: === lastVersionOf: projectName | versions | versions := self fileNames select: [ :f | f beginsWith: projectName , '-' ]. ^ (versions asSortedCollection: [ :v1 :v2 | (v1 copyFrom: (v1 indexOf: $.) + 1 to: (v1 lastIndexOf: $.)) asInteger (v2 copyFrom: (v2 indexOf: $.) + 1 to: (v2 lastIndexOf: $.)) asInteger ]) last === Cheers, Jannik On Nov 7, 2011, at 17:58 , Mariano Martinez Peck wrote: Hi guys. Is there a way to get a list of packages or packages names of a squeaksource repo? For example, I would love to do: Gofer it squeaksource: 'xxx'; allPackages. is that possible? Thanks -- Mariano http://marianopeck.wordpress.com --- Jannik Laval -- Lukas Renggli www.lukas-renggli.ch -- Mariano http://marianopeck.wordpress.com -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Best practices for overrides/extension methods with Monticello and correct packaging?
For an example, have a look at the package Helvetia-Loader in http://source.lukas-renggli.ch/helvetia. It verifies the expected sytem, patches Monticello, bootstraps the quasiquoting, replaces the compiler and parser infrastructure in multiple steps, ... Lukas On Monday, 7 November 2011, Stéphane Ducasse stephane.duca...@inria.fr wrote: if you look in the scripttloatder you can tell the MC that it should apply a list of package one after the other and not (by default collect all the classes and apply all the change together). Now another smart move is to think (if the license allows it) how you can push the hooks that you need to the community like that you are more customization and less override. Now part two, I hope that we will get a bootstrap working one of these days but for that we need to get time. Stef On Nov 7, 2011, at 11:29 PM, Stefan Marr wrote: Hi: I was wondering what the standard approach is to package rather invasive changes to core classes. Currently, I have everything in extension methods that override the existing methods in my own package. However, the monticello package is not actually loadable. So, I cannot just load my stuff into a new image via monticello. For instance, I modify #basicNew/#basicNew:, the Parser, the Encoder classes, etc. With my changes, these things depend on my own classes being properly initialized in the image. What is the best way to get that into a loadable/bootstrapable state? Do I need to split up all the stuff into different packages according to dependencies and then make sure that I can load those different packages in a well defined order? Or is there anything to tell Monticello to be smarter about loading the stuff? Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] crash of the vm on ubuntu
Yes, seems to work quite stable. Only with Eliot's VM though, not with any of the official Pharo VMs. Maybe consider updating them? Lukas On 4 November 2011 16:22, Jorge Ressia jorge.res...@gmail.com wrote: Hi guys, Flushing the selector is enough. Eliot fixed this problem some time ago. Look at the discussion http://forum.world.st/Re-Pharo-project-Troubles-with-flushCache-and-run-with-in-td3659114.html @Alex I have a test case that I built for Eliot. If you send me your image and VM I can try out to see if there is a similar problem. Cheers, On Fri, Nov 4, 2011 at 3:31 PM, Mariano Martinez Peck marianop...@gmail.com wrote: Flushing the behavior is way too much, since if I understand correctly, it will flush the whole method cache (including PICs etc ). In my experience, with the latest version, just flushing the selector is enough. It is not in your case? Cheers On Fri, Nov 4, 2011 at 3:18 PM, Alexandre Bergel alexandre.ber...@me.com wrote: What is still not clear to me is what you need to flush when replacing a method with an object. The selector, the old method, the new method, or the behavior? Last time I tried I got the best results flushing the behavior, but I would like to know what should be used for real. +1 I also flush the behavior. Alexandre On Friday, 4 November 2011, Alexandre Bergel alexandre.ber...@me.com wrote: Ok Thanks, we will try Alexandre On 4 Nov 2011, at 11:01, Mariano Martinez Peck wrote: On Fri, Nov 4, 2011 at 2:14 PM, Alexandre Bergel alexandre.ber...@me.com wrote: Hi! My students are experiencing frequent crashes of the CogVM when playing with Spy (a profiling framework that instrument compile methods and replace them during the execution). My students use a MooseOneClick bundle. I am not sure which version of the CogVM they use actually. Is there a way to check this? Anyone has experienced frequent crashes with Ubuntu? There were some issues with #cannotInterpret: and #run:with:in with previous versions of Cog. However, with the last version Eliot' Cog all of them are fixed Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- Mariano http://marianopeck.wordpress.com -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- Lukas Renggli www.lukas-renggli.ch -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- Mariano http://marianopeck.wordpress.com -- Jorge Ressia www.jorgeressia.com -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Headless PetitParser
Alberto, Have a look at the how TextLint (a PetitParser thingy that creates some output) is integrated into TextMate, Emacs, Vim, ... https://github.com/DamienCassou/textlint The Pharo VM is started through some (shell) scripts that are called by the respective editors (but these scripts also work independently): Emacs: https://github.com/DamienCassou/textlint/blob/master/textlint.bash TextMate: https://github.com/DamienCassou/textlint/blob/master/TextLint.tmbundle/Commands/Run%20TextLint.tmCommand Lukas On 6 November 2011 01:04, Stefan Marr ph...@stefan-marr.de wrote: Hi Alberto: On 05 Nov 2011, at 23:29, Alberto Bacchelli wrote: ./myParser -i fileToParse.txt -o outputFile.txt Is there any possibility to do that? Can a headless Pharo be a solution? If so, how can I start and use a headless Pharo? Is there any useful documentation/email about it? I attached the stuff I currently use. There might be better ways to do it, but the attached code is Squeak 3.9 and Pharo 1.3 compatible... [There might be bugs with regard to saving images and restarting etc. Have not checked whether that is the latest version of the code. But should be good enough to get an idea, and might be sufficient for your use case.] The HelloWorld class should get you started. On OSX you would need a fairly new VM, I think. The old ones did not play nice with the command-line. The hello world should look like this: $ your-vm-binary -headless your.image HelloWorld foo bar baz Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] crash of the vm on ubuntu
What is still not clear to me is what you need to flush when replacing a method with an object. The selector, the old method, the new method, or the behavior? Last time I tried I got the best results flushing the behavior, but I would like to know what should be used for real. Lukas On Friday, 4 November 2011, Alexandre Bergel alexandre.ber...@me.com wrote: Ok Thanks, we will try Alexandre On 4 Nov 2011, at 11:01, Mariano Martinez Peck wrote: On Fri, Nov 4, 2011 at 2:14 PM, Alexandre Bergel alexandre.ber...@me.com wrote: Hi! My students are experiencing frequent crashes of the CogVM when playing with Spy (a profiling framework that instrument compile methods and replace them during the execution). My students use a MooseOneClick bundle. I am not sure which version of the CogVM they use actually. Is there a way to check this? Anyone has experienced frequent crashes with Ubuntu? There were some issues with #cannotInterpret: and #run:with:in with previous versions of Cog. However, with the last version Eliot' Cog all of them are fixed Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- Mariano http://marianopeck.wordpress.com -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Goods Test Runner Pharo 1.3 Issues
Not sure if this is related, but the collection hierarchy got refactored in Pharo at some point to include HashedCollection (AFAIR) as superclass. Maybe this broke something with the persistence of Sets and Dictionaries? Lukas On Tuesday, 1 November 2011, mail list mail.l...@ficonab.com wrote: I am trying to deploy a Pharo 1.3 image using Goods and running into some basic issues where my objects are not persisted by reachability. eg I put dictionary x at root under a key 'test' eg db root at: 'test' put x. db commit. Then at x i updated instance variable and add something to its dictionary and committ eg x intancevariable y at: 'key' put '' db commit looking at the root x does not get updated with y. I have the majority of the test cases pasing except for testIdentitySet and testFlushAllRemovesAllUnreferenced. In testIdentitySet the following failure | set x y y2 | set := KKIdentitySet database: dbOne. x := 1@1. y := 2@2. set add: x. set add: y. self assert: (set includes: x). self assert: (set includes: y). self deny: (set includes: 1@1). --fails set = (2@2,1@1) so it seems to think that x and 1@1 are the same. Which to me seems correct but I may be misunderstanding the testcase. Any thoughts or pointers to update my mistakes in using Goods db would be helpful. S. On Oct 31, 2011, at 5:49 PM, Marcus Denker wrote: 13320 - Issue 4945: Weird Settings filtering http://code.google.com/p/pharo/issues/detail?id=4945 -- Marcus Denker -- http://marcusdenker.de -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Is HudsonBuildTools test coverage report ready?
On 31 October 2011 11:02, Mariano Martinez Peck marianop...@gmail.com wrote: Hi Lukas. I was playing with the test coverage, I installed the emma plugin for Jenkis and I configure everything. However, I don't get any result but instead a: Emma: looking for coverage reports in the provided path: **/*-Coverage.xml Emma: no coverage files found in workspace. Was any report generated? Build step 'Record Emma coverage report' changed build result to FAILURE Finished: FAILURE I guess that from my xxx.tests.st I should call HDCoverageReport but I don't know how and it doesn't have class comments. What should I call from my .st ? I thought I could do something like HDCoverageReport runPackages: aListofPackages but I don't think that can work, because you need TWO parameters: the tests packages and the real packages. Any idea? You run HDCoverageReport exactly the same way as HDTestReport. HDCoverageReport uses exactly the same mechanism as the Test Runner to figure out the code you want calculate the coverage on. That is, you have to override #packageNamesUnderTest on the class side of one of your test classes. I don't know if HDCoverageReport still works, because I stopped using it when I started with Cog on Jenkins. It definitely works on traditional VMs. Probably today it works on Cog too. Lukas -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Is HudsonBuildTools test coverage report ready?
Cool, so what is your experience? Does it work well with the latest Cog? I should re-enable the coverage on my images again :-) Lukas On 31 October 2011 12:22, Mariano Martinez Peck marianop...@gmail.com wrote: You run HDCoverageReport exactly the same way as HDTestReport. HDCoverageReport uses exactly the same mechanism as the Test Runner to figure out the code you want calculate the coverage on. That is, you have to override #packageNamesUnderTest on the class side of one of your test classes. WowI wasn't aware of that. I always trigger the TestCoverage from the test runner and then I needed to select the package to which it should calculate the coverage... I don't know if HDCoverageReport still works, because I stopped using it when I started with Cog on Jenkins. It definitely works on traditional VMs. Probably today it works on Cog too. Yes, latest Cog works ok with test coverage, and HDCoverageReport works!! look the attached screenshot Thanks Lukas Lukas -- Lukas Renggli www.lukas-renggli.ch -- Mariano http://marianopeck.wordpress.com -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Is HudsonBuildTools test coverage report ready?
Last time I tried with the test runner (that uses essentially the same infrastructure) it didn't quite work for me yet. I had some rare random crashes and sometimes coverage results were not entirely correct. It improved with every new version of Cog, so maybe all problems are resolved now? :-) Also we have to check if the method lookup cache are flushed the same way as with the test runner. Could be that the two runners are out of sync. Lukas On 31 October 2011 12:30, Mariano Martinez Peck marianop...@gmail.com wrote: On Mon, Oct 31, 2011 at 12:27 PM, Lukas Renggli reng...@gmail.com wrote: Cool, so what is your experience? Does it work well with the latest Cog? Yes, as far as I can see yes. But it would be cool another guy test it also because there is no exact way to be sure whether it is working good or not. I just check the non-covered methods and I analyzed if they are correct not to be covered or not I should re-enable the coverage on my images again :-) Sure, but first give it a try with a normal image with latest cog. If it works then update your jenkis :) Lukas On 31 October 2011 12:22, Mariano Martinez Peck marianop...@gmail.com wrote: You run HDCoverageReport exactly the same way as HDTestReport. HDCoverageReport uses exactly the same mechanism as the Test Runner to figure out the code you want calculate the coverage on. That is, you have to override #packageNamesUnderTest on the class side of one of your test classes. WowI wasn't aware of that. I always trigger the TestCoverage from the test runner and then I needed to select the package to which it should calculate the coverage... I don't know if HDCoverageReport still works, because I stopped using it when I started with Cog on Jenkins. It definitely works on traditional VMs. Probably today it works on Cog too. Yes, latest Cog works ok with test coverage, and HDCoverageReport works!! look the attached screenshot Thanks Lukas Lukas -- Lukas Renggli www.lukas-renggli.ch -- Mariano http://marianopeck.wordpress.com -- Lukas Renggli www.lukas-renggli.ch -- Mariano http://marianopeck.wordpress.com -- Lukas Renggli www.lukas-renggli.ch
Re: [Pharo-project] Comment Syntax
The problem is that both #/* and #/* are valid binary operators, so they don't work well for comments. I don't really remember what I proposed a few years ago, although I remember that exactly the same proposal was made. What would work is to use something like * and * (or any other double thing that starts with a double quote). Like this the comments could contain double quotes. As a short term solution you can also put your comments into single quotes. Unused string literals are removed by the compiler. Lukas On 31 October 2011 22:00, Stéphane Ducasse stephane.duca...@inria.fr wrote: Me too. Sean lukas proposed a syntax for that in the mailing-list a year ago. If you find it please resent it. Stef On Oct 31, 2011, at 9:12 PM, Sean P. DeNigris wrote: Would it be difficult/valuable to create an alternate comment syntax? I often find myself wanting to comment a large block itself containing comments. It would be nice to have something like C++'s /* */. I feel like this may have been brought up before, but couldn't find it searching the lists. Sean -- View this message in context: http://forum.world.st/Comment-Syntax-tp3961451p3961451.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. -- Lukas Renggli www.lukas-renggli.ch
