September 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Esug-list] New Mars examples: Package Browser and Test Runner

by kilon

ok found it in smalltalkhub and load it to the image, but trying CofigurationOfMars loadBleedingEdge gives me an error "error: name not found unix" . How I load it ? I am on Ubuntu 13.04 amd64. -- View this message in context: http://forum.world.st/New-Mars-examples-Package-Browser-and-Test-Runner-tp4… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 24, 2013

Re: [Pharo-dev] Smalltalkhub - REST API :) (a.k.a. Sorry, if I broke it...^^)

by Stephan Eggermont

And please don't all at the same time download and run the DeprecationFinder code, until Nicolas tells you he wants to do a load test! Stephan

Sept. 24, 2013

Re: [Pharo-dev] Smalltalkhub - REST API :) (a.k.a. Sorry, if I broke it...^^)

by Stephan Eggermont

Hi Marcel, >my goal is to find the big ones to take a closer look at. Thus, next steps would be to fetch the latest MCZ of all projects and then analyze their contents. :) That is in DeprecationFinder. (load in a Moose 4.8 after loading NeoJSon). Current analysis is just getting the invocations from a MooseMonticelloImporter for the latest packageversion. It needs to be extended to also walk the team projects. Further steps would be to make it incremental and have a fuel file as artefact in a Jenkins build. Stephan

Sept. 24, 2013

Re: [Pharo-dev] [Esug-list] New Mars examples: Package Browser and Test Runner

by kilon

You did an awesome job, I had not the chance to try your code. I assume it on smalltalkhub but it is down , but will try your code ASAP on my UBUNTU. But from the videos its clear you have done very good job, thank you for contributing to pharo . google code link to a non existent website. Where exactly one can get the code ? -- View this message in context: http://forum.world.st/New-Mars-examples-Package-Browser-and-Test-Runner-tp4… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 24, 2013

Asking for commit rights to pharo 3 inbox

by kilon

Since it seems I will be submitting more slices, any chance of granting me committing right so I can easier move my slices from computer to computer and you avoid downloading manually my slices :) -- View this message in context: http://forum.world.st/Asking-for-commit-rights-to-pharo-3-inbox-tp4709969.h… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 24, 2013

Re: [Pharo-dev] Smalltalkhub - REST API :) (a.k.a. Sorry, if I broke it...^^)

by Marcel Taeumel

Thank you, my goal is to find the big ones to take a closer look at. Thus, next steps would be to fetch the latest MCZ of all projects and then analyze their contents. :) Btw: Maybe it should not be possible to fetch a user's email address via /hub/users/username considering privacy issues. Best, Marcel -- View this message in context: http://forum.world.st/Smalltalkhub-REST-API-a-k-a-Sorry-if-I-broke-it-tp470… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 24, 2013

Re: [Pharo-dev] Smalltalkhub - REST API :) (a.k.a. Sorry, if I broke it...^^)

by kilon

So My Dear Lords whats the punishment for breaking smalltalkhub ? I propose 100 bug fixes as punishment of this man reckless behavior :D I was about to open a thread about sthub 502. Definetly a fun way to kill smalltalk hub. DiegoLont wrote > Yes, > > We already found out that putting load on smalltalkhub causes a crash. > Please take a look at deprecation finder at smalltalkhub. If you want a > list of all projects (and all calls this project does) we can provide this > in a fuel file. > > Regards, > Stephan and Diego > > On Sep 24, 2013, at 8:53 AM, Marcel Taeumel wrote: > >> Hi! :) >> >> I am just trying out a tool thus querying the SmalltalkHub instance at >> smalltalkhub.com via its REST interface. Unfortunately, it just stopped >> responding when I tried to fetch all MC file listings in a query. >> >> It now gives a 502. Sorry for that. :-/ >> >> Best, >> Marcel >> >> P.S.: I only wanted to retrieve this list once having it cached locally. >> But >> the query did not finish even once... >> >> <http://forum.world.st/file/n4709948/smalltalkhub-browser.png> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Smalltalkhub-REST-API-a-k-a-Sorry-if-I-broke-it-tp470… >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> -- View this message in context: http://forum.world.st/Smalltalkhub-REST-API-a-k-a-Sorry-if-I-broke-it-tp470… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Sept. 24, 2013

Re: [Pharo-dev] Smalltalkhub - REST API :) (a.k.a. Sorry, if I broke it...^^)

by Diego Lont

Yes, We already found out that putting load on smalltalkhub causes a crash. Please take a look at deprecation finder at smalltalkhub. If you want a list of all projects (and all calls this project does) we can provide this in a fuel file. Regards, Stephan and Diego On Sep 24, 2013, at 8:53 AM, Marcel Taeumel wrote: > Hi! :) > > I am just trying out a tool thus querying the SmalltalkHub instance at > smalltalkhub.com via its REST interface. Unfortunately, it just stopped > responding when I tried to fetch all MC file listings in a query. > > It now gives a 502. Sorry for that. :-/ > > Best, > Marcel > > P.S.: I only wanted to retrieve this list once having it cached locally. But > the query did not finish even once... > > <http://forum.world.st/file/n4709948/smalltalkhub-browser.png> > > > > -- > View this message in context: http://forum.world.st/Smalltalkhub-REST-API-a-k-a-Sorry-if-I-broke-it-tp470… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Sept. 24, 2013

Re: [Pharo-dev] SHA1 changed ??

by Esteban Lorenzano

cool :) this was annoying me too :P On Sep 23, 2013, at 8:45 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > https://pharo.fogbugz.com/f/cases/11664/SHA1-hashStream-should-return-a-Byt… > > with slice > > On 13 Sep 2013, at 15:38, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Bump. >> >> Max ? >> >> On 30 Aug 2013, at 13:52, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> On 30 Aug 2013, at 13:39, Marcus Denker <marcus.denker(a)inria.fr> wrote: >>> >>>> On Aug 30, 2013, at 1:35 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >>>> >>>>> I'm not aware of such a change... >>>>> this is probably an error/side effect of something else. >>>>> >>>> This is a side effect of the merging of the two nearly identical but duplicated SHA1 implementations in the imageâ¦ >>>> >>>> https://pharo.fogbugz.com/f/cases/5469/SHA1-duplicated-implementations >>> >>> I want to wait for Max to respond/explain. >>> >>> But according to http://en.wikipedia.org/wiki/Sha1 >>> >>> "SHA-1 produces a 160-bit (20-byte) hash value. A SHA-1 hash value is typically expressed as a hexadecimal number, 40 digits long." >>> >>> The previous contract of returning a ByteArray of size 20 is more correct than an Integer, although both are mathematically equivalent. It is also very easy to send #hex to a ByteArray to get the most common human representation of such a hash. >>> >>>>> Esteban >>>>> >>>>> On Aug 29, 2013, at 3:05 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>>> >>>>>> Max, >>>>>> >>>>>> Why was the contract of SHA1>>hashStream: changed ? >>>>>> >>>>>> It used to return a ByteArray like other HashFunction subclasses, now it returns an Integer. I see that you also changed the tests with this assumption. >>>>>> >>>>>> MD5 hashMessage: 'foo'. >>>>>> >>>>>> #[172 189 24 219 76 194 248 92 237 239 101 79 204 196 164 216] >>>>>> >>>>>> SHA1 hashMessage: 'foo'. >>>>>> >>>>>> 68123873083688143418383284816464454849230703155 >>>>>> >>>>>> It broke Zinc-WebSockets in 3.0 and now I will have to do an ugly hack to make the code work on multiple Pharo versions. >>>>>> >>>>>> Can you please explain ? >>>>>> >>>>>> Sven >>>>> >>>>> >>>> >>> >> > >

Sept. 24, 2013

Re: [Pharo-dev] [NB] Trying to implement a ReadStream on NBExternalAddress

by Luc Fabresse

2013/9/24 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > Isn't Eliot just implementing this feature, having a segment of non > relocatable objects? > AFAIU, yes ;-) Cheers, Luc > > > 2013/9/23 Igor Stasenko <siguctua(a)gmail.com> > >> >> >> >> On 23 September 2013 21:40, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >>> >>> >>> >>> On 23 September 2013 16:23, Camillo Bruni <camillobruni(a)gmail.com>wrote: >>> >>>> Hi Jan, >>>> >>>> I think I will add the ByteArray accessor to NBExternalAddress today >>>> or tomorrow since I need it as well for another project. >>>> >>>> hmm, reading from memory into bytearray can be done with memory copy: >>> >>> inputs: address , offset , size to read >>> >>> newAddress := NBExternalAddress value: address value + offset. >>> buffer := ByteArray new: size. >>> NativeBoost memCopy: newAddress to: buffer size: size. >>> >>> same way, writing, just swap the source and destination: >>> >>> newAddress := NBExternalAddress value: address value + offset. >>> buffer "is given from somewhere". >>> NativeBoost memCopy: buffer to: newAddress size: size. >>> >>> but as Jan noted, you cannot tell to write starting at specified offset >>> from/to bytearray, e.g.: >>> >>> copy from: address to: buffer + someOffset >>> neither: >>> copy from: buffer + someOffset to: someAddress >>> >>> this where we need to introduce special 'field address' type, so you >>> can construct it like this: >>> >>> offsetAddress := buffer nbAddressAt: offset. >>> >>> so then you can use it to pass to any function, which expects address, >>> like memory copy >>> or any foreign function. >>> >>> Since objects are moving in memory, we cannot calculate address of field >>> before hand: >>> >>> address := NBExternalAddress value: someObject address + offset. >>> >>> because if GC will happen, after computing such address and its actual >>> use, >>> you will read/write to wrong location. >>> >> >> ** after computing and *before* actual use ** >> >> >>> Thus we should keep oop + offset up to the point of passing it to >>> external function, under >>> controllable conditions, that guarantee there's no GC is possible. >>> >>> >>> Things would be much simpler if we could have pinning, isnt? :) >> >> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > >

Sept. 24, 2013