- Pharo-users - lists.pharo.org

ICFP contest 4th of August

by Sebastian Heidbrink

Hi! Just in case somebody might have missed this: http://icfpcontest.org/ Seabstian

Aug. 3, 2015

Re: [Pharo-users] [ann] jdt2famix - an open-source java importer project

by Tudor Girba

Hi (again), The project below is made possible by JNIPort. Thanks, Joachim! Cheers, Doru On Sun, Aug 2, 2015 at 11:26 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I would like to announce the jdt2famix project. This aims to be an > open-source solution for importing Java projects into Moose: > http://www.smalltalkhub.com/#!/~Moose/Jdt2Famix > > The project is based on: > - JDT for raw parsing. This is implemented in Java. > - JNIPort for delegating to Pharo the Java methods that visit the Java AST. > > Installation details can be found on the main project page. > > The current importing logic is rudimentary, but the first goal was to > setup the whole ping-pong between Pharo and Java. This one works, and I am > quite happy about that. You can take a look at the JdtImporterTest. > > CAVEATS: > - Due to a problem in JNIPort, currently, this project only works in Moose > 5.0. > - Also, for now it works out of the box only for Mac OS X. > - And, on top of that, it requires Java 1.6 for now (until we will get the > Spur VM on 64 bits). > > There are still quite some challenges left, but once we get this going, we > would also be able to use deep AST analysis live, and to do incremental > model update when something changes on disk. Furthermore, if it scales, > this would not be based on an intermediary MSE file anymore. > > I would like to ask for help in several directions: > 1. Implement the full model import. This would require diving into JDT and > implementing the corresponding mapping logic. I spent a few days on this. > It is hairy, but it is not that impossible (only it has a ton of edge > cases). This should be test driven, in that, for each case, we need to have > a corresponding sample. > 2. Fix JNIPort to work in Pharo 5. > 3. Get the whole thing to work out of the box for Linux and Windows. > 4. Check scalability. > > Please let me know your opinions, and let me know if you would like to > participate. > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- www.tudorgirba.com "Every thing has its own flow"

Aug. 2, 2015

Re: [Pharo-users] Comparison for SequencableCollection

by Joachim Tuchel

I think nobody's arguing that comparison of Collections is wrong per se. It's just that such an extension should not be part of the core libraries, or put differently, Smalltalk should not be extended in that direction, because the assumptions about what may or may not be the meaning of comparing two SequencableCollections are not universal. To me, JavaScript is far from being a positive argument ;-) Joachim > Am 02.08.2015 um 21:50 schrieb webwarrior <reg(a)webwarrior.ws>: > > Your use case (comparing containers using pluggable comparison for > items) is pretty common. > > And what I was suggesting won't solve that problem. > > However, it will make sequencable collections with comparable items > comparable. That's it. If we have comparison defined for Point, why not > have it for arrays? > > And no one forces you to define #= or #< for your objects if you don't > want to. > > > On 02.08.2015 20:23, Peter UhnÃ¡k [via Smalltalk] wrote: > > > > ... snip ... > > > > View this message in context: Re: Comparison for SequencableCollection > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 2, 2015

Re: [Pharo-users] Comparison for SequencableCollection

by webwarrior

Your use case (comparing containers using pluggable comparison for items) is pretty common. And what I was suggesting won't solve that problem. However, it will make sequencable collections with comparable items comparable. That's it. If we have comparison defined for Point, why not have it for arrays? And no one forces you to define #= or #< for your objects if you don't want to. On 02.08.2015 20:23, Peter UhnÃ¡k [via Smalltalk] wrote: > > ... snip ... > -- View this message in context: http://forum.world.st/Comparison-for-SequencableCollection-tp4840704p484072… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 2, 2015

Re: [Pharo-users] Comparison for SequencableCollection

by Peter UhnÃ¡k

On Sun, Aug 2, 2015 at 6:44 PM, webwarrior <reg(a)webwarrior.ws> wrote: > > On 02.08.2015 19:02, Peter UhnÃ¡k [via Smalltalk] wrote: > > > (a b c) = (b a c) if a = b > > > > (a b c) < (b a c) if a < b > > The semantics are well defined. > > > > > > Since you mentioned JavaScript, you should know that you can't compare > > arrays with ==, because it does object comparison. > > > > No. Sorted collection maintains order of its elements, and I'm > talking > > about order on [the set of] sequencable collections > > > > This will make sense only if the objects have overriden their #=. > > Which also means that it is not very useful to use #<, because you can't > > define order without overriding #=. > > Technically, you can: > (a < b) not and: [ (b < a) not ] "a and b are equal" > Well if the two objects are not comparable, then you've just made them equal. :) > > But of course it's reasonable to implement #= and #hash along with #< - > that's what TComparable requires. > Implementing #=/#hash just to achieve ordering seems like a terrible idea, considering #= affects a lot and often it will be context-dependent. (Sometimes you want to compare objects one way, sometimes another, that's why there's #sorted: method.) > > > Compare it to sorting a collection, where you can either do #sorted, > > which will do "a <= b" by default, but you can still do #sorted: and > > specify the sort order, dtto with PluggableDictionary etc. > > So if anything, it would make more sense to be able to block-based > > testing (without relying on #<), because more often then not you will > > have your values wrapped in some (bigger) objects. > > Something like #compare:using: where second argument is a binary block? > Might be a solution, although not as elegant. > Question is what are return values of the method and what is expected to > be returned from the block? > String>>#compare: returns integer from 1 to 3; > SequencableCollection>>#findBinary: expects either 0, negative or > positive integer; #sorted: expects boolean; #max:, #min:, etc. expect > object to be compared. My point was, that in object world you will usually have more complex objects than just strings. For example you have a class "Person" that has "name" and "surname" attributes. Suddenly you can't override #=, because it doesn't make sense in context to lexicographic ordering... do you want the order to be by name or by surname? Or something else? That's why I wrote that implementing just #< has very constrained use-case, because you can't specify what you want to order. Of course you can do "somePeople collect: #name < (otherPeople collect: #name)" but you still want it to be done on People collection, not the collection of strings. Or maybe I am forcing not very common use case?

Aug. 2, 2015

Re: [Pharo-users] Comparison for SequencableCollection

by webwarrior

On 02.08.2015 19:02, Peter UhnÃ¡k [via Smalltalk] wrote: > (a b c) = (b a c) if a = b > > (a b c) < (b a c) if a < b > The semantics are well defined. > > > Since you mentioned JavaScript, you should know that you can't compare > arrays with ==, because it does object comparison. > > No. Sorted collection maintains order of its elements, and I'm talking > about order on [the set of] sequencable collections > > This will make sense only if the objects have overriden their #=. > Which also means that it is not very useful to use #<, because you can't > define order without overriding #=. Technically, you can: (a < b) not and: [ (b < a) not ] "a and b are equal" But of course it's reasonable to implement #= and #hash along with #< - that's what TComparable requires. > Compare it to sorting a collection, where you can either do #sorted, > which will do "a <= b" by default, but you can still do #sorted: and > specify the sort order, dtto with PluggableDictionary etc. > So if anything, it would make more sense to be able to block-based > testing (without relying on #<), because more often then not you will > have your values wrapped in some (bigger) objects. Something like #compare:using: where second argument is a binary block? Might be a solution, although not as elegant. Question is what are return values of the method and what is expected to be returned from the block? String>>#compare: returns integer from 1 to 3; SequencableCollection>>#findBinary: expects either 0, negative or positive integer; #sorted: expects boolean; #max:, #min:, etc. expect object to be compared. > And finally "Because in almost every programming language..." is not an > argument. > You could argue that "1 + 2 * 3" should return "7", because that's how > every language does it and that's how mathematicians did it for > thousands of years. And yet Smalltalk happily returns "9" and yet it > makes sense, and some could argue that it's even better. > > Peter > > On Sun, Aug 2, 2015 at 4:59 PM, Alexandre Bergel <[hidden email] > </user/SendEmail.jtp?type=node&node=4840722&i=0>> wrote: > > > I'd say it is questonable if SequenceableCollections should be comparable by default. > > +1 > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > ------------------------------------------------------------------------ > If you reply to this email, your message will be added to the discussion > below: > http://forum.world.st/Comparison-for-SequencableCollection-tp4840704p484072… > > To unsubscribe from Comparison for SequencableCollection, click here > <http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&no…>. > NAML > <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > -- View this message in context: http://forum.world.st/Comparison-for-SequencableCollection-tp4840704p484072… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 2, 2015

Re: [Pharo-users] Comparison for SequencableCollection

by Peter UhnÃ¡k

> > (a b c) = (b a c) if a = b (a b c) < (b a c) if a < b > The semantics are well defined. Since you mentioned JavaScript, you should know that you can't compare arrays with ==, because it does object comparison. No. Sorted collection maintains order of its elements, and I'm talking > about order on [the set of] sequencable collections This will make sense only if the objects have overriden their #=. Which also means that it is not very useful to use #<, because you can't define order without overriding #=. Compare it to sorting a collection, where you can either do #sorted, which will do "a <= b" by default, but you can still do #sorted: and specify the sort order, dtto with PluggableDictionary etc. So if anything, it would make more sense to be able to block-based testing (without relying on #<), because more often then not you will have your values wrapped in some (bigger) objects. And finally "Because in almost every programming language..." is not an argument. You could argue that "1 + 2 * 3" should return "7", because that's how every language does it and that's how mathematicians did it for thousands of years. And yet Smalltalk happily returns "9" and yet it makes sense, and some could argue that it's even better. Peter On Sun, Aug 2, 2015 at 4:59 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > I'd say it is questonable if SequenceableCollections should be > comparable by default. > > +1 > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Aug. 2, 2015

Re: [Pharo-users] Comparison for SequencableCollection

by Alexandre Bergel

> I'd say it is questonable if SequenceableCollections should be comparable by default. +1 Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 2, 2015

Re: [Pharo-users] Comparison for SequencableCollection

by webwarrior

No. Sorted collection maintains order of its elements, and I'm talking about order on [the set of] sequencable collections On 02.08.2015 15:46, jtuchel [via Smalltalk] wrote: > Am 02.08.15 um 14:11 schrieb webwarrior: > > I was surprised when discovered that in Pharo comparison is not > defined for > > lists, arrays and similar datastructures. > > > > Because in almost every programming language (F#, Python, Javascript > just to > > name few) you can compare lists, arrays, etc. By convention, the > ordering is > > lexicographical, just like in strings. > > BTW: This would be SortedCollection, not OrderedCollection or its > superclass. > Still I am not convinced that I really need an implementation of #< in > SequencableCollection. Too many ways to interpret what greater or equal > or lower could mean... > > > > > > ------------------------------------------------------------------------ > If you reply to this email, your message will be added to the discussion > below: > http://forum.world.st/Comparison-for-SequencableCollection-tp4840704p484070… > > To unsubscribe from Comparison for SequencableCollection, click here > <http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&no…>. > NAML > <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > -- View this message in context: http://forum.world.st/Comparison-for-SequencableCollection-tp4840704p484070… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 2, 2015

Re: [Pharo-users] Comparison for SequencableCollection

by webwarrior

On 02.08.2015 15:44, jtuchel [via Smalltalk] wrote: > I'd say it is questonable if SequenceableCollections should be > comparable by default. > > is (a b c) equal or lower than (b a c) ? > Doesn't this depend heavily on what is in the Collection and what the > meaning of the Sequence of two Collections is? (a b c) = (b a c) if a = b (a b c) < (b a c) if a < b The semantics are well defined. Of course, it depends on what's in collection! That's the point - we compare collections by their content. If some elements are not comparable, we'll get DoesNotUnderstand - expected behavior when comparing non-comparable objects. It's the same story as with equality. > So I'd say there is not much use in putting comparisons into the base > class library, because there is a ton of assumptions about the > Collections in whatever implementation one can imagine. I would assume > that this is the job of some business object that holds objects in a > SequenceableCollection. Don't you think? There is only one assumption - that elements of the first collection are comparable to the elements of the second collection. And I think that we shouldn't multiply entities beyond necessity by creating a class when using simple datastructure would be sufficient. > The fact that other languages provide such an implementation doesn't > mean much to me, to be honest. I choose a SequencableCollection in order > to keep objects in a certain order, nothing more, nothing less. That's why we have methods such as polynomialEval: and asDigitsToPower:do: (and I'm not talking about extension methods) ? > I think it is important to not get "overridden" by the fact that > something is extremely easy to do in Smalltalk. We can easily make bad > mistakes, just because we can. > > Just my 2 cents > > Joachim > > Am 02.08.15 um 14:11 schrieb webwarrior: > > > I was surprised when discovered that in Pharo comparison is not > defined for > > lists, arrays and similar datastructures. > > > > Because in almost every programming language (F#, Python, Javascript > just to > > name few) you can compare lists, arrays, etc. By convention, the > ordering is > > lexicographical, just like in strings. > > > > It took little time to add needed methods to SequencableCollection, > but I > > think its better to have them in core library (core image, or how do you > > call it?). > > > > > > > > -- > > View this message in context: > http://forum.world.st/Comparison-for-SequencableCollection-tp4840704.html > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. -- View this message in context: http://forum.world.st/Comparison-for-SequencableCollection-tp4840704p484070… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Aug. 2, 2015