- Pharo-dev - lists.pharo.org

[Pharo-project] Smalltalk idiom

by Ramiro Diaz Trepat

I have a simple question regarding the use of a proper idiom.I had to create a matrix (n X m) of random values and I used a line similar to this one: NMatrix withRows: ((1 to: n) collect: [ :i | random next: m ]). Since Smalltalk is so neat for its collection handling, I obviously did not like to write that line. I thought that I did not want to explicitly create the interval, nor use a block that requires an argument that I also don't use. The question, finally, is if there an elegant way of replicating the behaviour of #collect: but without the argument? In my case, I thought it would be great for Integer to have something like #timesCollect: that would allow me to rewrite the line above as: NMatrix withRows: (n timesCollect: [ random next: m ]) Does anyone else think that this would be an useful method to have? Cheers r.

May 20, 2009

Re: [Pharo-project] Tracing changes in MC (was: ThirtyTwoBitRegister methods removed)

by Alexandre Bergel

I meant in Monticello. What I often need is the following: - the name of the committer who removed/added a class/method - the comment of the version in which this change occurs. Am I the only one who experience this? Alexandre On 19 May 2009, at 23:33, Michael Roberts wrote: > To be honest I think that is the wrong way around. I never need to > search for a method. I am normally in a debugger so have the method. > Just want to work out when it changed. However if the only way to > solve that is to write a top down search rather than a bottom up sort > of approach then go for it. It should be possible to spawn the search > from all the browsers. > > Thanks mike > > On Tuesday, May 19, 2009, Alexandre Bergel <alexandre(a)bergel.eu> > wrote: >> the topic of the discussion is not in sync with the thread topic. >> >> My answer to Nicolas' was: >> Here is an idea: >> - Adding a button 'search' in a Monticello repository >> inspector (the >> one you get when opening a repository) >> - with a 'search' button, you can then enter a method >> location such >> as TextMorphEditor>>keystroke: >> - the list of versions that either added the method or >> removed it >> according to the ancestors. >> >> How does that sound? I can work on it. >> >> Cheers, >> Alexandre >> >> >> Begin forwarded message: >> >>> From: Michael Roberts <mike(a)mjr104.co.uk> >>> Date: 19 May 2009 19:06:13 CEDT >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] ThirtyTwoBitRegister methods removed >>> Reply-To: Pharo-project(a)lists.gforge.inria.fr >>> >>> In general I would like to see a bit more envy tool like support in >>> mc. I have not checked out OT or newer mc versions to see what is >>> implemented. I would like the method vesions tool to map into a mc >>> version and to quickly go from the class to mc view. Can we do this >>> already? If not this would be really useful but I appreciate it >>> has to >>> be built. Otherwise I too scratch my head trying to work out where >>> all >>> the changes come in. I am not for a second proposing the envy model >>> but the tool was integrated nicely. >>> thanks mike >>> >>> On Tuesday, May 19, 2009, Mariano Martinez Peck >>> <marianopeck(a)gmail.com> wrote: >>>> >>>> >>>> On Tue, May 19, 2009 at 6:46 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com >>>>> wrote: >>>> >>>> To me, this raises a more general question. >>>> How can we trace a particular change in Pharo? >>>> Why when and where this change did occur? I know all is in the >>>> Monticello repository, but is there a quick and convenient way to >>>> answer such a question? I mean avoiding a manual scan of each and >>>> every Monticello version... >>>> >>>> Or is it logged in the ChangeSet? In this case, what hidden menu or >>>> code snippet will help tracking the change? >>>> >>>> Or should we use the issue tracker? Ideally, the reason for every >>>> change should be logged here. And every Monticello uploaded should >>>> refer to an issue. Even if this were strictly applied, not sure >>>> that >>>> is the way to retrieve information at such a detailed level. >>>> >>>> If none of these tools can provide an easy answer, then yes, >>>> requests >>>> on mailing lists, IRC, or internet search can provide a much >>>> efficient >>>> answer. But that's the signature a tool is lacking. >>>> >>>> I am agree. Actually, I thought to add in my email a generic >>>> question of that because I faced this problem several times and I >>>> didn't know what to do. >>>> >>>> >>>> >>>> I wish Mariano gets an answer, but an answer on the method would be >>>> more profitable to every one. >>>> No problem. Perhaps someone knows haha. >>>> >>>> >>>> >>>> Cheers >>>> >>>> Nicolas >>>> >>>> 2009/5/19 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>>>> Hi folks. I noticed that this two methods were removed from >>>>> ThirtyTwoBitRegister: >>>>> >>>>> asByteArray >>>>> ^ ByteArray with: (low bitAnd: 16rFF) with: (low bitShift: >>>>> -8) with: >>>>> (hi bitAnd: 16rFF) with: (hi bitShift: -8) >>>>> >>>>> >>>>> >>>>> reverseLoadFrom: aByteArray at: index >>>>> "Load my 32-bit value from the four bytes of the given >>>>> ByteArraystarting at the given index. Consider the first byte to >>>>> contain the >>>>> mostsignificant bits of the word (i.e., use big-endian byte >>>>> ordering)." >>>>> >>>>> hi := ((aByteArray at: index + 3) bitShift: 8) + >>>>> ( aByteArray at: >>>>> index + 2). >>>>> low := ((aByteArray at: index + 1) bitShift: 8) + >>>>> ( aByteArray at: >>>>> index). >>>>> >>>>> >>>>> >>>>> I need them for Glorp. I looked but I didn't found a similar >>>>> message for >>>>> them. I don't think adding them as an extension is a good solution >>>>> here >>>>> since this seems to be very "internal". is there a reason of the >>>>> removing? >>>>> If not, could them be added again? If there are reason, which >>>>> should be the >>>>> best approach to fix this in mi case? >>>>> >>>>> I have no problem in commit them if you want. >>>>> >>>>> Thanks! >>>>> >>>>> Mariano >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- >>>>> project >>>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 20, 2009

Re: [Pharo-project] Tracing changes in MC (was: ThirtyTwoBitRegister methods removed)

by Alexandre Bergel

> However, there are few things to add: > > - the same situation can happen with removed classes, not only methods > - suppose I found in which version a method was removed. What can I > do ? just see commit comments. So, apart from that, we have to put a > description in the comment that explains what was removed for > example an even why. > > What do you think ? It makes sense. The method or the class could even be reintroduced. I will give a try in the next few days. Alexandre > > > Begin forwarded message: > > > From: Michael Roberts <mike(a)mjr104.co.uk> > > Date: 19 May 2009 19:06:13 CEDT > > To: Pharo-project(a)lists.gforge.inria.fr > > Subject: Re: [Pharo-project] ThirtyTwoBitRegister methods removed > > Reply-To: Pharo-project(a)lists.gforge.inria.fr > > > > In general I would like to see a bit more envy tool like support in > > mc. I have not checked out OT or newer mc versions to see what is > > implemented. I would like the method vesions tool to map into a mc > > version and to quickly go from the class to mc view. Can we do this > > already? If not this would be really useful but I appreciate it > has to > > be built. Otherwise I too scratch my head trying to work out where > all > > the changes come in. I am not for a second proposing the envy model > > but the tool was integrated nicely. > > thanks mike > > > > On Tuesday, May 19, 2009, Mariano Martinez Peck > > <marianopeck(a)gmail.com> wrote: > >> > >> > >> On Tue, May 19, 2009 at 6:46 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com > >> > wrote: > >> > >> To me, this raises a more general question. > >> How can we trace a particular change in Pharo? > >> Why when and where this change did occur? I know all is in the > >> Monticello repository, but is there a quick and convenient way to > >> answer such a question? I mean avoiding a manual scan of each and > >> every Monticello version... > >> > >> Or is it logged in the ChangeSet? In this case, what hidden menu or > >> code snippet will help tracking the change? > >> > >> Or should we use the issue tracker? Ideally, the reason for every > >> change should be logged here. And every Monticello uploaded should > >> refer to an issue. Even if this were strictly applied, not sure > that > >> is the way to retrieve information at such a detailed level. > >> > >> If none of these tools can provide an easy answer, then yes, > requests > >> on mailing lists, IRC, or internet search can provide a much > >> efficient > >> answer. But that's the signature a tool is lacking. > >> > >> I am agree. Actually, I thought to add in my email a generic > >> question of that because I faced this problem several times and I > >> didn't know what to do. > >> > >> > >> > >> I wish Mariano gets an answer, but an answer on the method would be > >> more profitable to every one. > >> No problem. Perhaps someone knows haha. > >> > >> > >> > >> Cheers > >> > >> Nicolas > >> > >> 2009/5/19 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >>> Hi folks. I noticed that this two methods were removed from > >>> ThirtyTwoBitRegister: > >>> > >>> asByteArray > >>> ^ ByteArray with: (low bitAnd: 16rFF) with: (low bitShift: > >>> -8) with: > >>> (hi bitAnd: 16rFF) with: (hi bitShift: -8) > >>> > >>> > >>> > >>> reverseLoadFrom: aByteArray at: index > >>> "Load my 32-bit value from the four bytes of the given > >>> ByteArraystarting at the given index. Consider the first byte to > >>> contain the > >>> mostsignificant bits of the word (i.e., use big-endian byte > >>> ordering)." > >>> > >>> hi := ((aByteArray at: index + 3) bitShift: 8) + > >>> ( aByteArray at: > >>> index + 2). > >>> low := ((aByteArray at: index + 1) bitShift: 8) + > >>> ( aByteArray at: > >>> index). > >>> > >>> > >>> > >>> I need them for Glorp. I looked but I didn't found a similar > >>> message for > >>> them. I don't think adding them as an extension is a good solution > >>> here > >>> since this seems to be very "internal". is there a reason of the > >>> removing? > >>> If not, could them be added again? If there are reason, which > >>> should be the > >>> best approach to fix this in mi case? > >>> > >>> I have no problem in commit them if you want. > >>> > >>> Thanks! > >>> > >>> Mariano > >>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- > project > >>> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 20, 2009

Re: [Pharo-project] New Pharo based on core 10309 with antialiased fonts

by StÃ©phane Ducasse

henrik May be we can find a slow machine for you :) if this could fuel your passion to fix that. Having a fast UI is still really important. Stef On May 19, 2009, at 10:24 PM, Henrik Sperre Johansen wrote: > FreetypeFont rendering is alot slower than StrikeFont rendering. > There's surely some microoptimizations possible, but one big > (theoretical at least) macro-level enhancement is: > - Currently, morphs by default do not respect the damagerect when > rendering submorphs, instead clipping by its own clippingBounds. > Which means however small the damage to the window was, all > submorphs WILL be redrawn. > Attached is a changeset which changes this, instead intersecting the > Morphs clippingBounds with the Canvas' current clipRect. > > Sadly, this will NOT improve typing performance by itself, as > another problem here is Morphs reporting waaaay too big damage rects > in alot of cases. (try evaluating (Preferences preferenceAt: > #debugShowDamage) preferenceValue: true, and see the damage reported > by a single keypress...) > This has to be rectified on a Morph by Morph basis, as well as > making the displayOn: method use the clipRect intelligently (see > MultiNewParagraph >> displayOn:using:at: for an example of this ). > Personally, I'm not affected enough to fuel the passion to do this, > but if anyone are, I suspect the steps described above are the ones > which will yield the best results, performancewise. > > So what's the changeset currently good for? (Non- > fastForMorphic)resizing of a simple morph that occludes only some of > another SystemWindow's submorphs should see some improvements. > Resizing a window with nothing below will probably suffer abit due > to the extra operation/garbage from the intersect: though. > I haven't had access to a slow enough machine to have visual > confirmation, nor any automated tests to test resizing performance, > so take it with a grain of salt as this is purely in theory :) (Or > file it in and do a quick visual check of the effects described > above if you're on a slow machine) > > Cheers, > Henry > > > On 18.05.2009 16:08, Adrian Lienhard wrote: >> >> I also noticed the slow responsiveness (and I am on a quite fast >> machine). >> Adrian >> >> On May 18, 2009, at 15:57 , Schwab,Wilhelm K wrote: >> >> >>> Damien, >>> >>> In a word, WOW. >>> >>> Have you changed the desktop menus somehow? A left click now (I >>> _think_ this is new) gives me a find-window menu, and it takes a >>> right click to get the world menu, which looks different to me. >>> Wait - this might just be themes? I seleected Vistary and things >>> are back to "normal." >>> >>> >>> One snag: I find this image to very sluggish on typing. In fairness >>> I am running Ubuntu on an older machine that isn't the fastest, but >>> it is still far more sluggish than even my recent web image (10303), >>> and that (I think) has lost some speed too. Sorry to keep harping >>> on this, but I type pretty fast (enough to draw complaints in a >>> crowded room). Maybe there is so much noise because every third key >>> is the backspace :) >>> >>> The anti-aliased fonts are wonderful, but for me at least, snappy >>> response to the keyboard is more important. Having both would be >>> great! >>> >>> Bill >>> >>> >>> >>> ________________________________________ >>> From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr >>> ] On Behalf Of Damien Cassou [damien.cassou(a)gmail.com] >>> Sent: Monday, May 18, 2009 8:02 AM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] New Pharo based on core 10309 with >>> antialiased fonts >>> >>> On Mon, May 18, 2009 at 1:51 PM, Adrian Lienhard <adi(a)netstyle.ch> >>> wrote: >>> >>>> I agree with Lukas, Bill, and Simon (that is, to change the default >>>> font to DejaVu Sans). >>>> >>> Ok, here is the new version. What do you think? >>> >>> font := LogicalFont familyName: 'DejaVu Sans' pointSize: 10. >>> codeFont := LogicalFont familyName: 'DejaVu Sans Mono' pointSize: 9. >>> titleFont := LogicalFont familyName: 'DejaVu Serif' pointSize: 11. >>> >>> Preferences setListFontTo: font. >>> Preferences setMenuFontTo: font. >>> Preferences setCodeFontTo: codeFont. >>> Preferences setButtonFontTo: font. >>> Preferences setSystemFontTo: font. >>> Preferences setWindowTitleFontTo: titleFont. >>> >>> -- >>> Damien Cassou >>> http://damiencassou.seasidehosting.st >>> >>> "Lambdas are relegated to relative obscurity until Java makes them >>> popular by not having them." James Iry >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> > > < > submorphsrespectingdamagerect > .st>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 20, 2009

Re: [Pharo-project] New Pharo based on core 10309 with antialiased fonts

by Damien Cassou

2009/5/19 Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no>: > FreetypeFont rendering is alot slower than StrikeFont rendering. > [...] http://code.google.com/p/pharo/issues/detail?id=832 http://code.google.com/p/pharo/issues/detail?id=833 -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

May 20, 2009

Re: [Pharo-project] Symbol>>value:value:

by StÃ©phane Ducasse

do you have a scenario for it? And I agree with lukas about value on Object Stef On May 20, 2009, at 12:52 AM, Tudor Girba wrote: > Hi, > > Given that in Pharo we have Symbol>>value:, are there any reasons not > to have also > > Symbol>>value: anObject value: anotherObject > ^ anObject perform: self with: anotherObject > > ? > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Yesterday is a fact. > Tomorrow is a possibility. > Today is a challenge." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 20, 2009

Re: [Pharo-project] Symbol>>value:value:

by Lukas Renggli

> Given that in Pharo we have Symbol>>value:, are there any reasons not > to have also > > Symbol>>value: anObject value: anotherObject > Â Â Â Â ^ anObject perform: self with: anotherObject While Symbol>>#value: is at the border of being readable, Symbol>>#value:value: is even worse. It is not immediately obvious what it does. The order of receiver and arguments is hardcoded and thus the construct cannot be applied in most cases without rewriting the code. Fixed arguments cannot be given. Instead of adding new #value: variants, we should rather try to remove Object>>#value which is a real nightmare ;-) Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

May 20, 2009

Re: [Pharo-project] Inspect it wrong shortcut

by Alexandr Batalshikov

On Windows XP evaluating "Preferences enable: #swapCOntrolAndAltKeys" and changing any settings in section keyboard of Preference Browser no any effects to any shortcuts. / Alexander. 2009/5/19 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > 2009/5/19 Alexandr Batalshikov <abatalshikov(a)gmail.com> > >> On Windows XP with pharo0.1-10309dev09.05.3.image:Alt+i -- run Inspect >> Alt+Shift+i -- run Explore >> Ctrl+i -- also run Explore >> >> and changing any setting in section "keyboard" in Preference Browser >> no any effects for me. >> > > Alexander: I created this ticket: > http://code.google.com/p/pharo/issues/detail?id=829 > > could you are your comments there ? > > Thanks > > Mariano > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 20, 2009

[Pharo-project] Symbol>>value:value:

by Tudor Girba

Hi, Given that in Pharo we have Symbol>>value:, are there any reasons not to have also Symbol>>value: anObject value: anotherObject ^ anObject perform: self with: anotherObject ? Cheers, Doru -- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

May 19, 2009

Re: [Pharo-project] Tracing changes in MC (was: ThirtyTwoBitRegister methods removed)

by Michael Roberts

To be honest I think that is the wrong way around. I never need to search for a method. I am normally in a debugger so have the method. Just want to work out when it changed. However if the only way to solve that is to write a top down search rather than a bottom up sort of approach then go for it. It should be possible to spawn the search from all the browsers. Thanks mike On Tuesday, May 19, 2009, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > the topic of the discussion is not in sync with the thread topic. > > My answer to Nicolas' was: > Here is an idea: > Â Â Â Â - Adding a button 'search' in a Monticello repository inspector (the > one you get when opening a repository) > Â Â Â Â - with a 'search' button, you can then enter a method location such > as TextMorphEditor>>keystroke: > Â Â Â Â - the list of versions Â that either added the method or removed it > according to the ancestors. > > How does that sound? I can work on it. > > Cheers, > Alexandre > > > Begin forwarded message: > >> From: Michael Roberts <mike(a)mjr104.co.uk> >> Date: 19 May 2009 19:06:13 CEDT >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] ThirtyTwoBitRegister methods removed >> Reply-To: Pharo-project(a)lists.gforge.inria.fr >> >> In general I would like to see a bit more envy tool like support in >> mc. I have not checked out OT or newer mc versions to see what is >> implemented. I would like the method vesions tool to map into a mc >> version and to quickly go from the class to mc view. Can we do this >> already? If not this would be really useful but I appreciate it has to >> be built. Otherwise I too scratch my head trying to work out where all >> the changes come in. I am not for a second proposing the envy model >> but the tool was integrated nicely. >> thanks mike >> >> On Tuesday, May 19, 2009, Mariano Martinez Peck >> <marianopeck(a)gmail.com> wrote: >>> >>> >>> On Tue, May 19, 2009 at 6:46 AM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com >>> > wrote: >>> >>> To me, this raises a more general question. >>> How can we trace a particular change in Pharo? >>> Why when and where this change did occur? I know all is in the >>> Monticello repository, but is there a quick and convenient way to >>> answer such a question? I mean avoiding a manual scan of each and >>> every Monticello version... >>> >>> Or is it logged in the ChangeSet? In this case, what hidden menu or >>> code snippet will help tracking the change? >>> >>> Or should we use the issue tracker? Ideally, the reason for every >>> change should be logged here. And every Monticello uploaded should >>> refer to an issue. Even if this were strictly applied, not sure that >>> is the way to retrieve information at such a detailed level. >>> >>> If none of these tools can provide an easy answer, then yes, requests >>> on mailing lists, IRC, or internet search can provide a much >>> efficient >>> answer. But that's the signature a tool is lacking. >>> >>> I am agree. Actually, I thought to add in my email a generic >>> question of that because I faced this problem several times and I >>> didn't know what to do. >>> >>> >>> >>> I wish Mariano gets an answer, but an answer on the method would be >>> more profitable to every one. >>> No problem. Perhaps someone knows haha. >>> >>> >>> >>> Cheers >>> >>> Nicolas >>> >>> 2009/5/19 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>>> Hi folks. I noticed that this two methods were removed from >>>> ThirtyTwoBitRegister: >>>> >>>> asByteArray >>>> Â Â Â Â ^ ByteArray with: (low bitAnd: 16rFF) with: (low bitShift: >>>> -8) with: >>>> (hi bitAnd: 16rFF) with: (hi bitShift: -8) >>>> >>>> >>>> >>>> reverseLoadFrom: aByteArray at: index >>>> Â Â Â Â Â "Load my 32-bit value from the four bytes of the given >>>> ByteArraystarting at the given index. Consider the first byte to >>>> contain the >>>> mostsignificant bits of the word (i.e., use big-endian byte >>>> ordering)." >>>> >>>> Â Â Â Â Â hi := ((aByteArray at: index + 3) bitShift: 8) + >>>> ( aByteArray at: >>>> index + 2). >>>> Â Â Â Â Â low := ((aByteArray at: index + 1) bitShift: 8) + >>>> ( aByteArray at: >>>> index). >>>> >>>> >>>> >>>> I need them for Glorp. I looked but I didn't found a similar >>>> message for >>>> them. I don't think adding them as an extension is a good solution >>>> here >>>> since this seems to be very "internal". is there a reason of the >>>> removing? >>>> If not, could them be added again? If there are reason, which >>>> should be the >>>> best approach to fix this in mi case? >>>> >>>> I have no problem in commit them if you want. >>>> >>>> Thanks! >>>> >>>> Mariano >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel Â http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 19, 2009