- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Keymapping Questions

by Guillermo Polito

This should not happen in the bleeding edge :) On Fri, Nov 4, 2011 at 1:34 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > I found another bug - creating a shortcut with no modifiers e.g. "$c > asShortcut" fires on c, shift-c, cmd-c... > > -- > View this message in context: > http://forum.world.st/Keymapping-Questions-tp3990667p3990743.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Nov. 5, 2011

Re: [Pharo-project] Keymapping Questions

by Guillermo Polito

On Fri, Nov 4, 2011 at 1:16 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > Where can I find documentation on Keymapping (if it exists)? > Hmmm, If you load the #bleedingEdge (which is pretty stable right now), there are several examples in the categories: Keymapping-Morph Keymapping-Editors Keymapping-Tools ... Also, most of the classes have comments, but I think I have to review them so far :). > > Here are the basics I have so far: > * the available set of shortcuts is per-class > * a shortcut is created by creating a builder method (similar to World Menu > registration) annotated with <keymap> > * shortcuts are grouped into categories > * categories (not individual shortcuts) are attached to Morph classes via > KMBuilder>>attachShortcutCategory:to: > * the system is updated when "KMPragmaKeymapBuilder uniqueInstance" resets > itself via #reset (but see problems below) > > Questions: > * What is the purpose of naming shortcuts? > Hmm, mainly, to bind a shortcut to a setting. And nothing else by now... So I use it as a kind of id :/. Maybe someone has a better approach... I was about to review it with Mariano tomorrow. > * Why are shortcuts held by categories as named entries and separately as > keymaps? > This is an idea I took from the original keymappings. I classify shortcuts in categories so you can: - attach a category to a specific class (letting its instances handle those keymaps) - attach a category to a specific instance (the same as above but in the instance level :) ) You can also attach a single shortcut in a morph like: someMorph on: aShortcut do: [ some task ] But this last (lets say) *annonimous* shortcut, can't be put into a setting. > > There seems to be a problem with updating shortcuts (esp. changing existing > ones): > * It seems that when an existing named shortcut is modified, eventually > KMShortcut>>shortcutHasChangedIn:by: is called, but this method does > nothing, so the shortcut never gets updated. Why is this? It seems like a > bug. > Hmm, strange. There are two implementations of this method in my image. One in KMShortcut and one in KMNoShortcut, one does nothing (on purpose with a comment :P) but the other has an implementation :/... > * When a <keymap> method is saved in OB, KMPragmaKeymapBuilder>>reset is > called twice - once via AnnouncementSubscription>>deliver:, and once via > KMPragmaKeymapBuilder>>event: > Hmm, I didn't knew this one :) > * Because KMRepository class>>reset is never called, it becomes very dirty > if shortcuts are repeatedly edited. For example, create a shortcut named > "myShortcut" with Cmd+D in Category "Test", now change its name and accept > the code. You will have two shortcuts with the same key combination. Now > change to Cmd+E and accept again. You will have three shortcuts, even > though > you have only one specified in your builder method... > > So it seems to me to keep integrity in the shortcuts, either: > * "KMRepository reset" when anything is changed, and start from scratch > * or, improve KMPragmaKeymapBuilder>>reset's ability to keep the system > clean. > I did it on purpose right now. The problem with resetting the KMContainer, is that you lose the customizations you did in the settings right now. Thinking aloud, maybe It would be good to provide two resets: - shallow reset. That resets the shortcuts but tries to remember the customizations done in the settings. This one can be done every time you modify a <keymap> annotated method. - deep reset. That just resets everything. You have to know that you are loosing everything here :). Thanks for the feedback :) Guille > Sean > > -- > View this message in context: > http://forum.world.st/Keymapping-Questions-tp3990667p3990667.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Nov. 5, 2011

Re: [Pharo-project] Simple vs. Easy

by Schwab,Wilhelm K

More stuff well said. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Jimmie Houchin [jlhouchin(a)gmail.com] Sent: Friday, November 04, 2011 9:19 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Simple vs. Easy I agree! I like the focus of Pharo and its goal of enabling people to get things done. Stef, I think you are doing a great job. Especially with the limited resources of the community. And I think you are doing a fantastic job of increasing the resources of the community. You have my profound thanks and appreciation. Jimmie On 11/4/2011 4:32 PM, Schwab,Wilhelm K wrote: > Sven, Sig, > > Well said. > > Bill > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven(a)beta9.be] > Sent: Friday, November 04, 2011 11:22 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Simple vs. Easy > > Sure, Cuis is really cool as well as very impressive. > > However, it is limited: > > I want: > > Seaside > Moose > HTTP Client+Server > Monticello > Metacello > XML > JSON > Glorp > Database Access > FFI > UTF8 and other encodings > â¦ > > I want a practical Smalltalk that I can use to build useful applications, building on top of great frameworks. > > Pharo takes on all these and at the same time tries to simplify things, the hard way. > > Sven > > On 04 Nov 2011, at 14:35, Jimmie Houchin wrote: > >> Forward with permission from Juan Vuletich Fri, 04 Nov 2011 08:42:03 -0300 >> >> Hi Folks, >> >> I'm answering you off-list because I'm not subscribed to the Pharo list. >> Feel free to forward this there, if you wish. >> >> I think it is great to put focus on simplicity (an objective value) over >> easyness (a subjective value). Rich also makes a good critic to usual >> practices, including the dichotomy between understanding and TDD (test >> driven development). >> >> However, the value of simplicity is not something new. The difference >> between essential complexity and accidental complexity is the heart of >> "No Silver Bullet â Essence and Accidents of Software Engineering" (by >> Fred Brooks, 1986) and "There Is a Silver Bullet" (by Brad Cox, 1990, >> http://drdobbs.com/184407534) It is also central to Smalltalk, see >> "Design Principles Behind Smalltalk" (by Dan Ingalls, 1981, >> http://classes.soe.ucsc.edu/cmps112/Spring03/readings/Ingalls81.html) >> These three articles might be the most important writings on software >> engineering ever. >> >> The problem with this discussion is that everybody will claim simplicity >> is a crucial objective of their project. However, Pharo and Squeak don't >> realize (or don't want to realize) that simplicity appears only by >> removing complexity, never by adding more of it. >> >> Cuis is a Squeak fork with the #1 objective of being simple and >> understandable. It is the result of more than 10 years suffering the >> accidental complexity in Squeak, comparing with other Smalltalks, >> together with a lot of reflection and work, by me and others. It is, I >> believe, the only Smalltalk in active development that pursues this >> objective of the original Smalltalk-80 project. You can get it from >> http://www.jvuletich.org/Cuis/Index.html . Browse it a bit. Take >> statistics (lines of code, etc). Compare. You might have a nice surprise. >> >> Jimmie, you asked "How can we move Pharo to be a better answer to Simple >> vs. Easy?". My answer is: start anew. Rebase on top of Cuis. Give up >> feature list as a priority, and focus on simplicity. Make a list of the >> features in Pharo that are really important, and not part of Cuis, and >> turn them into optional packages. Make that list as short as possible! >> Worry more about code quality and less about discarding potentially >> useful stuff, that is not good enough. >> >> Cheers, >> Juan Vuletich

Nov. 5, 2011

Re: [Pharo-project] Simple vs. Easy

by Jimmie Houchin

I agree! I like the focus of Pharo and its goal of enabling people to get things done. Stef, I think you are doing a great job. Especially with the limited resources of the community. And I think you are doing a fantastic job of increasing the resources of the community. You have my profound thanks and appreciation. Jimmie On 11/4/2011 4:32 PM, Schwab,Wilhelm K wrote: > Sven, Sig, > > Well said. > > Bill > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven(a)beta9.be] > Sent: Friday, November 04, 2011 11:22 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Simple vs. Easy > > Sure, Cuis is really cool as well as very impressive. > > However, it is limited: > > I want: > > Seaside > Moose > HTTP Client+Server > Monticello > Metacello > XML > JSON > Glorp > Database Access > FFI > UTF8 and other encodings > â¦ > > I want a practical Smalltalk that I can use to build useful applications, building on top of great frameworks. > > Pharo takes on all these and at the same time tries to simplify things, the hard way. > > Sven > > On 04 Nov 2011, at 14:35, Jimmie Houchin wrote: > >> Forward with permission from Juan Vuletich Fri, 04 Nov 2011 08:42:03 -0300 >> >> Hi Folks, >> >> I'm answering you off-list because I'm not subscribed to the Pharo list. >> Feel free to forward this there, if you wish. >> >> I think it is great to put focus on simplicity (an objective value) over >> easyness (a subjective value). Rich also makes a good critic to usual >> practices, including the dichotomy between understanding and TDD (test >> driven development). >> >> However, the value of simplicity is not something new. The difference >> between essential complexity and accidental complexity is the heart of >> "No Silver Bullet â Essence and Accidents of Software Engineering" (by >> Fred Brooks, 1986) and "There Is a Silver Bullet" (by Brad Cox, 1990, >> http://drdobbs.com/184407534) It is also central to Smalltalk, see >> "Design Principles Behind Smalltalk" (by Dan Ingalls, 1981, >> http://classes.soe.ucsc.edu/cmps112/Spring03/readings/Ingalls81.html) >> These three articles might be the most important writings on software >> engineering ever. >> >> The problem with this discussion is that everybody will claim simplicity >> is a crucial objective of their project. However, Pharo and Squeak don't >> realize (or don't want to realize) that simplicity appears only by >> removing complexity, never by adding more of it. >> >> Cuis is a Squeak fork with the #1 objective of being simple and >> understandable. It is the result of more than 10 years suffering the >> accidental complexity in Squeak, comparing with other Smalltalks, >> together with a lot of reflection and work, by me and others. It is, I >> believe, the only Smalltalk in active development that pursues this >> objective of the original Smalltalk-80 project. You can get it from >> http://www.jvuletich.org/Cuis/Index.html . Browse it a bit. Take >> statistics (lines of code, etc). Compare. You might have a nice surprise. >> >> Jimmie, you asked "How can we move Pharo to be a better answer to Simple >> vs. Easy?". My answer is: start anew. Rebase on top of Cuis. Give up >> feature list as a priority, and focus on simplicity. Make a list of the >> features in Pharo that are really important, and not part of Cuis, and >> turn them into optional packages. Make that list as short as possible! >> Worry more about code quality and less about discarding potentially >> useful stuff, that is not good enough. >> >> Cheers, >> Juan Vuletich

Nov. 5, 2011

Re: [Pharo-project] Simple vs. Easy

by Schwab,Wilhelm K

Stef, Please count me as a believer :) Pharo is evolving into a very nice system. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Friday, November 04, 2011 5:04 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Simple vs. Easy I wrote an answer and throw it away. I do not want to argue and keep my positive energy :) We will see in 5 years from now what will be the situation. Because we are getting more and more agile contrary to what people believe. We are making deep changes and working on the infrastructure of the system but with the challenge that we have users. And we want happy and powerful users. Infrastructure work that often invisible at first but after a while they really pay off. I want a system that people can use. The goal of Pharo is a system to build other systems. Now for 1.4 I would like to remove the rest of MethodReference, PseudoClass and Friends. Stef > Forward with permission from Juan Vuletich Fri, 04 Nov 2011 08:42:03 -0300 > > Hi Folks, > > I'm answering you off-list because I'm not subscribed to the Pharo list. > Feel free to forward this there, if you wish. > > I think it is great to put focus on simplicity (an objective value) over > easyness (a subjective value). Rich also makes a good critic to usual > practices, including the dichotomy between understanding and TDD (test > driven development). > > However, the value of simplicity is not something new. The difference > between essential complexity and accidental complexity is the heart of > "No Silver Bullet â Essence and Accidents of Software Engineering" (by > Fred Brooks, 1986) and "There Is a Silver Bullet" (by Brad Cox, 1990, > http://drdobbs.com/184407534) It is also central to Smalltalk, see > "Design Principles Behind Smalltalk" (by Dan Ingalls, 1981, > http://classes.soe.ucsc.edu/cmps112/Spring03/readings/Ingalls81.html) > These three articles might be the most important writings on software > engineering ever. > > The problem with this discussion is that everybody will claim simplicity > is a crucial objective of their project. However, Pharo and Squeak don't > realize (or don't want to realize) that simplicity appears only by > removing complexity, never by adding more of it. > > Cuis is a Squeak fork with the #1 objective of being simple and > understandable. It is the result of more than 10 years suffering the > accidental complexity in Squeak, comparing with other Smalltalks, > together with a lot of reflection and work, by me and others. It is, I > believe, the only Smalltalk in active development that pursues this > objective of the original Smalltalk-80 project. You can get it from > http://www.jvuletich.org/Cuis/Index.html . Browse it a bit. Take > statistics (lines of code, etc). Compare. You might have a nice surprise. > > Jimmie, you asked "How can we move Pharo to be a better answer to Simple > vs. Easy?". My answer is: start anew. Rebase on top of Cuis. Give up > feature list as a priority, and focus on simplicity. Make a list of the > features in Pharo that are really important, and not part of Cuis, and > turn them into optional packages. Make that list as short as possible! > Worry more about code quality and less about discarding potentially > useful stuff, that is not good enough. > > Cheers, > Juan Vuletich > >

Nov. 4, 2011

Re: [Pharo-project] Simple vs. Easy

by Schwab,Wilhelm K

Sven, Sig, Well said. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Sven Van Caekenberghe [sven(a)beta9.be] Sent: Friday, November 04, 2011 11:22 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Simple vs. Easy Sure, Cuis is really cool as well as very impressive. However, it is limited: I want: Seaside Moose HTTP Client+Server Monticello Metacello XML JSON Glorp Database Access FFI UTF8 and other encodings â¦ I want a practical Smalltalk that I can use to build useful applications, building on top of great frameworks. Pharo takes on all these and at the same time tries to simplify things, the hard way. Sven On 04 Nov 2011, at 14:35, Jimmie Houchin wrote: > Forward with permission from Juan Vuletich Fri, 04 Nov 2011 08:42:03 -0300 > > Hi Folks, > > I'm answering you off-list because I'm not subscribed to the Pharo list. > Feel free to forward this there, if you wish. > > I think it is great to put focus on simplicity (an objective value) over > easyness (a subjective value). Rich also makes a good critic to usual > practices, including the dichotomy between understanding and TDD (test > driven development). > > However, the value of simplicity is not something new. The difference > between essential complexity and accidental complexity is the heart of > "No Silver Bullet â Essence and Accidents of Software Engineering" (by > Fred Brooks, 1986) and "There Is a Silver Bullet" (by Brad Cox, 1990, > http://drdobbs.com/184407534) It is also central to Smalltalk, see > "Design Principles Behind Smalltalk" (by Dan Ingalls, 1981, > http://classes.soe.ucsc.edu/cmps112/Spring03/readings/Ingalls81.html) > These three articles might be the most important writings on software > engineering ever. > > The problem with this discussion is that everybody will claim simplicity > is a crucial objective of their project. However, Pharo and Squeak don't > realize (or don't want to realize) that simplicity appears only by > removing complexity, never by adding more of it. > > Cuis is a Squeak fork with the #1 objective of being simple and > understandable. It is the result of more than 10 years suffering the > accidental complexity in Squeak, comparing with other Smalltalks, > together with a lot of reflection and work, by me and others. It is, I > believe, the only Smalltalk in active development that pursues this > objective of the original Smalltalk-80 project. You can get it from > http://www.jvuletich.org/Cuis/Index.html . Browse it a bit. Take > statistics (lines of code, etc). Compare. You might have a nice surprise. > > Jimmie, you asked "How can we move Pharo to be a better answer to Simple > vs. Easy?". My answer is: start anew. Rebase on top of Cuis. Give up > feature list as a priority, and focus on simplicity. Make a list of the > features in Pharo that are really important, and not part of Cuis, and > turn them into optional packages. Make that list as short as possible! > Worry more about code quality and less about discarding potentially > useful stuff, that is not good enough. > > Cheers, > Juan Vuletich > >

Nov. 4, 2011

Re: [Pharo-project] Storing all source code in a relational database

by StÃ©phane Ducasse

Thanks alan for this post. I think that same. :) > I don't agree with that. There's certainly an impedance mismatch with Smalltalk code and relational databases, but there's also an impedance mismatch between Smalltalk code and file systems. Things like git which are custom-built to operate against a particular idea of source code and the operations on it very fast don't necessarily work well with Smalltalk-style operations like "show me the versions of this method". > > Cincom has spent a lot of time recently on Store, but only part of that involves the database. And much of the difficulty in the database part is not inherent to mapping the code to a database, but is because the original design of the relational schema and the way Store talked to it are very very bad, and can't easily be changed without breaking access to the database for older versions. We will change the schema to something much better at some point, but it's something that we really can't do incrementally, so we're being careful with it. > > ENVY has some very nice features, but I'd say that it shows some weaknesses relative to more modern systems. For example, it is very intrusive to make a version, and it is extremely sensitive to network latency. > > A database designed specifically for source code, and with the sort of operations that Smalltalk source code control would like to be able to do quickly would obviously be the ideal choice. Like relational databases, you'd want it to be extremely reliable, scalable, transactional, and have many different free implementations easily available on all platforms, with enough standardization that they are all reasonably compatible. A relational database isn't necessarily the best choice in all circumstances, but I don't think it's an obviously bad one either. > >> >> Reg Krock >> 3 November, 2011 10:42 AM >> >> >> Igor, >> >> I am emailing you offline but I just do not get why people are so interested in storing source code in a relational database. >> >> We have objects, there is a known mismatch between the object and relational world. So how does the relational database help out? >> >> Cincom has spent many man-years attempting to make STORE work well. A few grad students wrote ENVY in the 80's and it is a way superior in most ways to all other code repositories. >> >> Has anyone at INRIA looked at ENVY? >> >> Regards, >> >> Reg >> >> From: Igor Stasenko <siguctua(a)gmail.com> >> To: Pharo-project(a)lists.gforge.inria.fr >> Sent: Thursday, November 3, 2011 10:00:31 AM >> Subject: Re: [Pharo-project] Storing all source code in a relational database >> >> On 3 November 2011 00:20, Stephan Eggermont <stephan(a)stack.nl> wrote: >> > ... is a waste of time and computing resources. Relational databases are optimized >> > for specific usage scenarios. CAD systems and source code management systems >> > are the archetypical examples of systems that are a bad fit and will kill the performance >> > of a relational database. Of course 30 years later you can brute force it, but that doesn't >> > make it a good idea. Git is far superior to rdb based systems for the day-to-day work >> > and the analytics should be done from a ram-based object model. >> > >> >> Completely agree with you. But i think if you can store code in >> database, which one to use is a matter of taste >> (knowledge/availability etc). >> If we could have a nice abstraction for managing sources in image, >> then choosing where to store it is not a big deal. >> >> > Stephan >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> >> >> >> Igor Stasenko >> 3 November, 2011 10:00 AM >> >> >> On 3 November 2011 00:20, Stephan Eggermont <stephan(a)stack.nl> >> wrote: >> >>> ... is a waste of time and computing resources. Relational databases are optimized >>> for specific usage scenarios. CAD systems and source code management systems >>> are the archetypical examples of systems that are a bad fit and will kill the performance >>> of a relational database. Of course 30 years later you can brute force it, but that doesn't >>> make it a good idea. Git is far superior to rdb based systems for the day-to-day work >>> and the analytics should be done from a ram-based object model. >>> >>> >> >> Completely agree with you. But i think if you can store code in >> database, which one to use is a matter of taste >> (knowledge/availability etc). >> If we could have a nice abstraction for managing sources in image, >> then choosing where to store it is not a big deal. >> >> >>> Stephan >>> >>> >> >> >> >> >> >> Stephan Eggermont >> 2 November, 2011 7:20 PM >> >> >> ... is a waste of time and computing resources. Relational databases are optimized >> for specific usage scenarios. CAD systems and source code management systems >> are the archetypical examples of systems that are a bad fit and will kill the performance >> of a relational database. Of course 30 years later you can brute force it, but that doesn't >> make it a good idea. Git is far superior to rdb based systems for the day-to-day work >> and the analytics should be done from a ram-based object model. >> >> Stephan

Nov. 4, 2011

Re: [Pharo-project] Simple vs. Easy

by StÃ©phane Ducasse

I wrote an answer and throw it away. I do not want to argue and keep my positive energy :) We will see in 5 years from now what will be the situation. Because we are getting more and more agile contrary to what people believe. We are making deep changes and working on the infrastructure of the system but with the challenge that we have users. And we want happy and powerful users. Infrastructure work that often invisible at first but after a while they really pay off. I want a system that people can use. The goal of Pharo is a system to build other systems. Now for 1.4 I would like to remove the rest of MethodReference, PseudoClass and Friends. Stef > Forward with permission from Juan Vuletich Fri, 04 Nov 2011 08:42:03 -0300 > > Hi Folks, > > I'm answering you off-list because I'm not subscribed to the Pharo list. > Feel free to forward this there, if you wish. > > I think it is great to put focus on simplicity (an objective value) over > easyness (a subjective value). Rich also makes a good critic to usual > practices, including the dichotomy between understanding and TDD (test > driven development). > > However, the value of simplicity is not something new. The difference > between essential complexity and accidental complexity is the heart of > "No Silver Bullet â Essence and Accidents of Software Engineering" (by > Fred Brooks, 1986) and "There Is a Silver Bullet" (by Brad Cox, 1990, > http://drdobbs.com/184407534) It is also central to Smalltalk, see > "Design Principles Behind Smalltalk" (by Dan Ingalls, 1981, > http://classes.soe.ucsc.edu/cmps112/Spring03/readings/Ingalls81.html) > These three articles might be the most important writings on software > engineering ever. > > The problem with this discussion is that everybody will claim simplicity > is a crucial objective of their project. However, Pharo and Squeak don't > realize (or don't want to realize) that simplicity appears only by > removing complexity, never by adding more of it. > > Cuis is a Squeak fork with the #1 objective of being simple and > understandable. It is the result of more than 10 years suffering the > accidental complexity in Squeak, comparing with other Smalltalks, > together with a lot of reflection and work, by me and others. It is, I > believe, the only Smalltalk in active development that pursues this > objective of the original Smalltalk-80 project. You can get it from > http://www.jvuletich.org/Cuis/Index.html . Browse it a bit. Take > statistics (lines of code, etc). Compare. You might have a nice surprise. > > Jimmie, you asked "How can we move Pharo to be a better answer to Simple > vs. Easy?". My answer is: start anew. Rebase on top of Cuis. Give up > feature list as a priority, and focus on simplicity. Make a list of the > features in Pharo that are really important, and not part of Cuis, and > turn them into optional packages. Make that list as short as possible! > Worry more about code quality and less about discarding potentially > useful stuff, that is not good enough. > > Cheers, > Juan Vuletich > >

Nov. 4, 2011

Re: [Pharo-project] Simple vs. Easy

by StÃ©phane Ducasse

:) come on igor all these strange alphabets are not useful :) Ok I will stop and continue to work on our future. Stef On Nov 4, 2011, at 4:24 PM, Igor Stasenko wrote: > Just as a follow-up. A simple example: > Cuis doesn't supports unicode. It simply doesn't exists in Cuis. > Does it makes it simpler? Of course. > Does it makes life simpler for development of modern applications? > Absolutely not. > Because as i repeated many times, a unicode and i18n support is a must > have in any modern system. > And unicode is not _potentially_ useful, which you can just simply > discard because it is not flawlessly implemented. It is used a lot by > people, who living outside a latin world. > > -- > Best regards, > Igor Stasenko. >

Nov. 4, 2011

[Pharo-project] UUID comparaison is Incorrect

by StÃ©phane Ducasse

I was thinking that we should get the same bug for you UUID because the code right now is < aMagnitude "Answer whether the receiver is less than the argument." 1 to: self size do: [:i | (self at: i) < (aMagnitude at: i) ifTrue: [^true]]. ^false. >> |a b| >> a := UUID fromString: '0608b9dc-02e4-4dd0-9f8a-ea45160df641'. >> b := UUID fromString: 'e85ae7ba-3ca3-4bae-9f62-cc2ce51c525e'. >> (a > b) = (b > a) returns true and this looks wrong :) What do you think? Stef Begin forwarded message: > From: Alan Knight <knight(a)acm.org> > Subject: Re: [vwnc] UUID Sorting Incorrect > Date: November 1, 2011 3:19:23 PM GMT+01:00 > To: Runar Jordahl <runar.jordahl(a)gmail.com> > Cc: vwnc(a)cs.uiuc.edu > Reply-To: knight(a)acm.org > > Thanks. Created AR 64162 > >> >> Runar Jordahl >> 25 October, 2011 7:13 AM >> >> >> Class UUID is included in beta in VisualWorks 7.8. It seems like #< is >> implemented incorrect. If you evaluate the statement below it answers >> true: >> >> |a b| >> a := UUID fromString: '0608b9dc-02e4-4dd0-9f8a-ea45160df641'. >> b := UUID fromString: 'e85ae7ba-3ca3-4bae-9f62-cc2ce51c525e'. >> (a > b) = (b > a) >> >> The fix is to change the method to this: >> >> < aMagnitude >> "Answer whether the receiver is less than the argument. Add an >> initial size check, in anticipation of greater than 128-bit >> Smalltalk-specific UUID type." >> >> | ss ms | >> >> ss := self size. >> ms := aMagnitude size. >> ss < ms >> ifTrue: [^true] >> ifFalse: [ >> ss > ms >> ifTrue: [^false] >> ifFalse: [ >> 1 to: self size do: [:i | >> (self at: i) < (aMagnitude at: i) ifTrue: [^true]. >> (self at: i) > (aMagnitude at: i) ifTrue: [^false]]. >> ^false]] >> >> >> Runar Jordahl >> blog.epigent.com >> _______________________________________________ >> vwnc mailing list >> vwnc(a)cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ > vwnc mailing list > vwnc(a)cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Nov. 4, 2011