December 2016 - Pharo-users

[ANN] TechTalks Jan and Feb

by Marcus Denker

Hi, We have fixed the next two tech talks: - 24 Jan 2017. Topic "Bloc/Brickâ https://association.pharo.org/event-2405619 - 28 Feb 2017. Topic: âRefelectivity" https://association.pharo.org/event-2407465 We added these as âEventsâ to the association website. People registered there will get the information how to participate via mail (and a mail pointing to the recording afterwards). This is therefor especially interesting for those not following the mailing lists. The idea is to have one each months, if you have ideas for topics (or want to do some yourself), send a mail. Blog post: http://pharo.org/news/techtalks17

Dec. 19, 2016

Re: [Pharo-users] Hash collision

by Andres Valloud

At first glance, that the failure code only sees "two" things when it should see "eight" seems to be problematic. Perhaps the primitive insists on hashing byte objects, and there is a distinction between "byte" objects and "word" objects (whatever "word" means, presumably a constant width integer across all platforms). I haven't looked at the code. From my perspective... back in the day that primitive used to hash bytes, and from what I saw here the failure code is hashing multi-byte things. If all of these observations are correct, then I'd say the failure code isn't doing what the primitive is doing, and in doing so it's introducing a lot of collisions that I'd like to believe the intended hash function wouldn't produce. Andres. On 12/18/16 23:05 , Martin McClure wrote: > On 12/18/2016 02:29 AM, Andres Valloud wrote: >> The primitive and the primitive failure code should behave the same? > > You think the primitive is faulty? I haven't looked at the primitive > code, but it just fails when given a Float. From the name, I'd guess > that it's designed for a byte object. The failure code certainly is. > > A new primitive designed for word objects, or new code such as I gave > earlier (though ugly) would work, though. > > Regards, > > -Martin >

Dec. 19, 2016

Re: [Pharo-users] iceberg and private github repos

by Tudor Girba

Hi, I had some troubles, that is why I asked :). But, I just tried again, and it looks like itâs working. Cheers, Doru > On Dec 19, 2016, at 9:54 AM, Nicolas Passerini <npasserini(a)gmail.com> wrote: > > Honestly I never tried, but I do not see why it wouldn't work. Please let me know if you find trouble. > > 2016-12-19 9:51 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > I guess is about credentials: you have the right user/pass, you will not have problemsâ¦ but thatâs just an âI guessâ :) > > (remember: iceberg just works with https security right nowâ¦ due current limitations on libgit2, not our fault :P) > > Esteban > > > On 19 Dec 2016, at 09:26, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > Hi, > > > > I have to work with a private GitHub repo. Is there a way to tell Iceberg to load from such a private repo? > > > > Cheers, > > Doru > > > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "We cannot reach the flow of things unless we let go." > > > > > > > > > > > > > -- www.tudorgirba.com www.feenk.com "Every now and then stop and ask yourself if the war you're fighting is the right one."

Dec. 19, 2016

Re: [Pharo-users] iceberg and private github repos

by Nicolas Passerini

Honestly I never tried, but I do not see why it wouldn't work. Please let me know if you find trouble. 2016-12-19 9:51 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > I guess is about credentials: you have the right user/pass, you will not > have problemsâ¦ but thatâs just an âI guessâ :) > > (remember: iceberg just works with https security right nowâ¦ due current > limitations on libgit2, not our fault :P) > > Esteban > > > On 19 Dec 2016, at 09:26, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > Hi, > > > > I have to work with a private GitHub repo. Is there a way to tell > Iceberg to load from such a private repo? > > > > Cheers, > > Doru > > > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "We cannot reach the flow of things unless we let go." > > > > > > > > > > > > >

Dec. 19, 2016

Re: [Pharo-users] iceberg and private github repos

by Esteban Lorenzano

I guess is about credentials: you have the right user/pass, you will not have problemsâ¦ but thatâs just an âI guessâ :) (remember: iceberg just works with https security right nowâ¦ due current limitations on libgit2, not our fault :P) Esteban > On 19 Dec 2016, at 09:26, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > I have to work with a private GitHub repo. Is there a way to tell Iceberg to load from such a private repo? > > Cheers, > Doru > > > -- > www.tudorgirba.com > www.feenk.com > > "We cannot reach the flow of things unless we let go." > > > > >

Dec. 19, 2016

iceberg and private github repos

by Tudor Girba

Hi, I have to work with a private GitHub repo. Is there a way to tell Iceberg to load from such a private repo? Cheers, Doru -- www.tudorgirba.com www.feenk.com "We cannot reach the flow of things unless we let go."

Dec. 19, 2016

DNU on materializing a fueled out exception

by Holger Freyther

Hi, I showed Pharo to a friend and wanted to show the nice feature of fueling out an exception and then using FLMaterializer class>>#materializeFromFileNamed: to load it back and get a debugger up. In Pharo5 I am presented a DNU instead. The DNU is on GTGenericStackDebugger as it doesn't understand the message Fuel is sending. What to fix, Fuel to use the new protocol or GTGenericStackDebugger to honor the old protocol? FueldOutStackDebugAction>>#serializeTestFailureContext: aContext toFileNamed: aFilename | serializer | serializer := FLSerializer newDefault. self encodeDebugInformationOn: serializer. serializer addPostMaterializationAction: [ :materialization | Smalltalk tools debugger openOn: Processor activeProcess context: materialization root label: 'External stack' contents: nil fullView: false ]. So it looks like now it should create a debug session first and then pass it to the debugger? I think loading new fuel in Pharo3.x is still possible so maybe it is best to re-add that protocol? comments? holger

Dec. 19, 2016

Re: [Pharo-users] Hash collision

by Martin McClure

On 12/18/2016 02:29 AM, Andres Valloud wrote: > The primitive and the primitive failure code should behave the same? You think the primitive is faulty? I haven't looked at the primitive code, but it just fails when given a Float. From the name, I'd guess that it's designed for a byte object. The failure code certainly is. A new primitive designed for word objects, or new code such as I gave earlier (though ugly) would work, though. Regards, -Martin

Dec. 19, 2016

Re: [Pharo-users] Protego - smart way to manage NIL's in business calculations

by Ben Coman

On Mon, Dec 19, 2016 at 2:43 AM, Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾ <assargaddon(a)gmail.com> wrote: > Sorry, I'm not sure I fully understand your idea. > It looks like trying to make another implementation of UndefinedObject, is > it? Just that. But it contains only business logic. I'm inclined to say both are the Null Object Pattern, but I'm not sure if concept truly applies to the system nil. https://www.tutorialspoint.com/design_pattern/null_object_pattern.htm https://www.cs.oberlin.edu/~jwalker/nullObjPattern/ > > What is the main difference between proposed MissingValue and > UndefinedObject? > It's just UndefinedObject is "too system" to intervene? Or something else? It could be nil for many reasons. Perhaps an initialization was missed. Mainly MissingValue avoids cluttering nil with custom logic. When looking via the Inspector or Debugger, a MissingValue provides a better indication of the status than a regular nil. Now you may want to avoid creating a new instance for each missing value. Perhaps the methods could have been added to the class side of MissingValue. Or use a singleton instance in the initialization. But I'm not sure of the pros/cons of each approach. Now I'm not saying MissingValue is the best way to go. Smalltalk does have the advantage of being able to add behaviour to nil and that might be sufficient for you. Just providing an additional way to think about it. cheers -ben > > > 2016-12-18 18:12 GMT+03:00 Ben Coman <btc(a)openinworld.com>: >> >> Thanks for sharing. A similar thing might be useful for dealing with >> "quality" of Process Variable measurement in industrial situations - >> where instruments fail from time to time. >> >> I'm not sure of all the pros and cons, but btw an alternative to >> hanging special behaviour on a method, would be to hang special >> behaviour on a MissingValue class that you could #initialize any >> instance variable to. >> >> Object subclass: #MissingValue >> instanceVariableNames: '' >> classVariableNames: '' >> package: 'AAAA' >> >> MissingValue >> * dummyValue >> self inform: 'debug trace - got here'. >> ^self >> >> MissingValue >> adaptToNumber: rcvr andSend: selector >> ^self perform: selector with: rcvr >> >> Collection >> sumProtected >> ^ self >> inject: 0 >> into: [ :sum :each | sum + each value] >> >> Usage... >> >> c := {1.1 * MissingValue new. 1.2 * 10. MissingValue new * 1.3. 10 * >> 1.4}. >> "==> an Array(aMissingValue 12.0 aMissingValue 14.0)" >> >> c sumExcludeMissing >> "==> 26.0" >> >> cheers -ben >> >> On Sun, Dec 18, 2016 at 6:45 PM, Ð®ÑÐ¸Ð¹ ÐÐ¸ÑÐ¾Ð½ÐµÐ½ÐºÐ¾ <assargaddon(a)gmail.com> >> wrote: >> > Imagine, you have some object with amount and price variables. >> > And you want to calculate total, put this totals to collection and >> > calculate >> > grand total. >> > >> > Naive implementation will be something like >> > total := amount * price for the first task >> > and something like >> > grandTotal := totals sum for the latter one. >> > >> > But what if amount or price are nil's? >> > You can add nil checks, of course: total := (amount ifNil:[0]) * (price >> > ifNil: [0]). >> > And then what if totals will be empty? More checks. >> > Is it really wise to have total to be zero if amount is nil? More >> > ifTrue:ifFalse: code. >> > And then you want to add amount := total / price calculation, and you >> > realize that both total and price may be nil, and price may be zero. >> > More and more and more checks. >> > >> > Protego (http://www.smalltalkhub.com/#!/~assargadon/Protego) adds >> > "protected" versions of common operators and methods. >> > >> > So, you just put >> > total := amount *@ price >> > and >> > grandTotal := totals sum_protected >> > into your code - and everything just works. >> > >> > total will be nil if any of the operands are nil. grandTotal will be >> > calculated normally, even for empty totals collection (will return nil >> > for >> > empty collection). >> > Collection can hold nil's and it will work anyway. If all elements of >> > the >> > collection is nil, result will be nil. >> > >> > Protected version of addition and subtraction will treat nil's as zeros >> > until both operands are nil - then it will return nil. >> > There are protected versions of comparisions, too. >> > >> > It's quite simple idea, which is still very useful, and it makes code >> > much >> > more readable, clean and self-commenting. >> > >> > That's why I have extracted this part of SmallPOS framework, and have >> > published it as separate package to use it in other, non-SmallPOS >> > applications. >> >

Dec. 19, 2016

whisper/porcini in Java

by Robert Withers

Voix-basse-mourde is whisper and herkutatti is porcini. I have the Java PBE working bit identical to Squeak, but the DBL_AESede protocol is not yet installing. Then the encoders for asn1der and json need implementation and Squeak and Java will work together again. find the code here, after logging in: https://gitlab.com/des-lapins-internationale best, Rabbit

Dec. 18, 2016