- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [ANN] Pharo Sprint June 30

by Pavel Krivanek

Right now for Pharo 7 you will need to download image from here: https://ci.inria.fr/pharo/view/7.0/job/70-Bootstrap-32bit/ And because of a Monticello issue you will need to have your clone in image working directory, in the folder named 'pharo-core' (the other alternative is to reload all packages). Then you need to switch this repository to the particular commit that was used for the image bootstrap. You can get the hash with: SystemVersion current commitHash ...and this cannot be done now from Iceberg. Then you can create issue branches and pull request. One goal of the sprint can be to make this all easier ;-) Cheers, -- Pavel 2017-06-23 10:57 GMT+02:00 Juraj Kubelka <juraj.kubelka(a)icloud.com>: > Great! > > Is the the Zeroconf Script the right one to use for the Pharo sprint? > curl get.pharo.org/70+vm | bash > > Currently it shows > Pharo 6.0 > Latest update: #60499 > > Can we still produces slices during the sprint? > I will appreciate any advice according to on going changes, in particular, > using GitHub. > > Thanks! > Juraj > > El 23-06-2017, a las 10:09, Marcus Denker <marcus.denker(a)inria.fr> > escribiÃ³: > > Hi! > > Next Friday, June 30 will be the next Pharo Sprint! > > It will start 10:00am. (Local Time Paris). > > For more infos, see: *https://association.pharo.org/event-2492492 > <https://association.pharo.org/event-2492492>* > > Marcus > > >

June 23, 2017

Re: [Pharo-dev] [ANN] Pharo Sprint June 30

by Juraj Kubelka

Great! Is the the Zeroconf Script the right one to use for the Pharo sprint? curl get.pharo.org/70+vm | bash Currently it shows Pharo 6.0 Latest update: #60499 Can we still produces slices during the sprint? I will appreciate any advice according to on going changes, in particular, using GitHub. Thanks! Juraj > El 23-06-2017, a las 10:09, Marcus Denker <marcus.denker(a)inria.fr> escribiÃ³: > > Hi! > > Next Friday, June 30 will be the next Pharo Sprint! > > It will start 10:00am. (Local Time Paris). > > For more infos, see: https://association.pharo.org/event-2492492 <https://association.pharo.org/event-2492492> > > Marcus

June 23, 2017

Recursively downloading Pharo packages / Building images with Nix

by Luke Gorrie

Howdy! I want to build Pharo images using Nix <https://nixos.org/nix/>. On the one hand this should look basically like the Jenkins scripts, but on the other hand the build must run inside a sandbox that is isolated from the network. So I need to download all of the code that I need ahead of time because I am not able to contact Github, SmalltalkHub, etc, once the build is running. I am not sure how to approach this problem yet but I have a preliminary question. Is there an easy way that I could "recursively" download all the Smalltalk code (etc) required for an application onto the local filesystem, and then load this into a Pharo image that does not have network access? Concrete example - How could I write a Pharo script that downloads all the software required to install Moose in a standard Pharo 6.0 image? Then how could I load that into an image off the local filesystem? I feel like there should be a solution here, since Monticello seems to be able to cache packages locally on the filesystem, but I don't how enough experience to quite know how to approach it. If this is possible then the "utopian" vision could be to recursively download every Pharo package that exists, in every relevant version, and make them available in the Nix universe. This is what Nix does with Python, R, Emacs, etc packages. Or if this turns out to be difficult for some reason then I could perhaps build the Pharo image externally - e.g. on the Inria Jenkins - and then import that into Nix as an opaque binary. This is probably the simplest solution but it is not very appealing from my Nix-centric viewpoint because I won't have visibility into what has changed between one image build and the next. Feedback would be much appreciated! -Luke P.S. Screenshot from the Pharo part of my application that is starting to come together, visualizing Lua JIT compiler IR code to make it more understandable than disassembly listings: https://github.com/raptorjit/raptorjit/pull/63#issuecomment-310138536.

June 23, 2017

[ANN] Pharo Sprint June 30

by Marcus Denker

Hi! Next Friday, June 30 will be the next Pharo Sprint! It will start 10:00am. (Local Time Paris). For more infos, see: https://association.pharo.org/event-2492492 Marcus

June 23, 2017

Ideas for TechTalks wanted

by Marcus Denker

Hi! We need to setup the dates and topics for the next tech talks, they are always the last tuesday of the month. We have two kinds: -> presentation of a demo with youtube live, then Q&A (one person talks) -> More open discussion just on Discord with Audio Chat about a topic (one person started and guides a discussion) We need topic ideas and people who take the lead role for the second part of the year (August to December). Marcus

June 23, 2017

Techtalk June 27 postponed to July 25

by Marcus Denker

Hi, As too many people can not take part next week Tuesday, we decided to move the Pharo6/Pharo7 roundtable to July 25. https://association.pharo.org/event-2492469 <https://association.pharo.org/event-2492469> Marcus

June 23, 2017

Re: [Pharo-dev] Iceberg diff colours seem reversed?

by Yuriy Tymchuk

I have to look into it, because the colors were reversed 100% and then I swapped them. And now I donât know (need some sleep, Iâll look tomorrow) Uko > On 22 Jun 2017, at 18:18, Tim Mackinnon <tim(a)testit.works> wrote: > > Itâs worth saying that the diff view on Epicea appears to be correct assuming left is previous and right is new (so I think it also shows the panes the other way around like I expected). > > Tim > >> On 22 Jun 2017, at 17:03, Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>> wrote: >> >> I think the left to right or right to left is probably a very opinionated thing (and I think Araxis, another tool Iâve used does it the other way around). >> >> However the colour coding is something that should properly communicate what is going on - and Iâm curious if anyone else has noticed it seems to be wrong (it sounds like for you its definitely confusing). >> >> I think there are known bugs in iceberg (not sure how much on the diff view - I also noticed that class comments donât seem to appear in the diff and I also see spurious method categorisation differences as well). >> >> Tim >> >>> On 22 Jun 2017, at 06:51, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: >>> >>> I didn't look at the iceberg diff right now. But I can say whenever I see a diff view in pharo it is so confusing I never know what I see. In the changes window I alwas switch from diff to source to see at least what I have now. Maybe a general problem how to put chronological change. And maybe for left-to-right readers to only way is older left - newer right >>> >>> Norbert >>> >>> Am 22.06.2017 um 03:40 schrieb Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: >>> >>>> Hi Guys - when you launch the Synchronize window in iceberg - is it me, or are the colour highlights backwards (and possibly the ordering of the panes)? >>>> >>>> If the left pane is my working copy, and I've added some code to a method - why does it appear in red on the left (which typically means deleted?). I notice that in IntelliJ (and other tools) your working changes are typically on the right and things you add are in Green on that right hand side. >>>> >>>> I think that ordering and colour coding make more sense - from -> to, and red is deleted, green is added. >>>> >>>> Of course I can live with the different pane ordering, but I think the colours might be wrong? >>>> >>>> Tim >> >

June 22, 2017

Re: [Pharo-dev] Error in ByteArray>>booleanAt:

by Sven Van Caekenberghe

> On 22 Jun 2017, at 17:39, Raffaello Giulietti <raffaello.giulietti(a)lifeware.ch> wrote: > > Hi, > > the current (Pharo 6) code reads > > ^(self integerAt: byteOffset size: 1 signed: false) == true > > so it always returns false, as no integer is identical to true. > > > Instead, it should read > > ^(self integerAt: byteOffset size: 1 signed: false) ~= 0 > > implementing the usual convention that 0 maps to false and every other value maps to true. > > Greetings > Raffaello Good catch, probably a typo. IMO, there should have been unit tests to validate such code.

June 22, 2017

Re: [Pharo-dev] Iceberg diff colours seem reversed?

by Tim Mackinnon

Itâs worth saying that the diff view on Epicea appears to be correct assuming left is previous and right is new (so I think it also shows the panes the other way around like I expected). Tim > On 22 Jun 2017, at 17:03, Tim Mackinnon <tim(a)testit.works> wrote: > > I think the left to right or right to left is probably a very opinionated thing (and I think Araxis, another tool Iâve used does it the other way around). > > However the colour coding is something that should properly communicate what is going on - and Iâm curious if anyone else has noticed it seems to be wrong (it sounds like for you its definitely confusing). > > I think there are known bugs in iceberg (not sure how much on the diff view - I also noticed that class comments donât seem to appear in the diff and I also see spurious method categorisation differences as well). > > Tim > >> On 22 Jun 2017, at 06:51, Norbert Hartl <norbert(a)hartl.name <mailto:norbert@hartl.name>> wrote: >> >> I didn't look at the iceberg diff right now. But I can say whenever I see a diff view in pharo it is so confusing I never know what I see. In the changes window I alwas switch from diff to source to see at least what I have now. Maybe a general problem how to put chronological change. And maybe for left-to-right readers to only way is older left - newer right >> >> Norbert >> >> Am 22.06.2017 um 03:40 schrieb Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: >> >>> Hi Guys - when you launch the Synchronize window in iceberg - is it me, or are the colour highlights backwards (and possibly the ordering of the panes)? >>> >>> If the left pane is my working copy, and I've added some code to a method - why does it appear in red on the left (which typically means deleted?). I notice that in IntelliJ (and other tools) your working changes are typically on the right and things you add are in Green on that right hand side. >>> >>> I think that ordering and colour coding make more sense - from -> to, and red is deleted, green is added. >>> >>> Of course I can live with the different pane ordering, but I think the colours might be wrong? >>> >>> Tim >

June 22, 2017

Re: [Pharo-dev] Iceberg diff colours seem reversed?

by Tim Mackinnon

I think the left to right or right to left is probably a very opinionated thing (and I think Araxis, another tool Iâve used does it the other way around). However the colour coding is something that should properly communicate what is going on - and Iâm curious if anyone else has noticed it seems to be wrong (it sounds like for you its definitely confusing). I think there are known bugs in iceberg (not sure how much on the diff view - I also noticed that class comments donât seem to appear in the diff and I also see spurious method categorisation differences as well). Tim > On 22 Jun 2017, at 06:51, Norbert Hartl <norbert(a)hartl.name> wrote: > > I didn't look at the iceberg diff right now. But I can say whenever I see a diff view in pharo it is so confusing I never know what I see. In the changes window I alwas switch from diff to source to see at least what I have now. Maybe a general problem how to put chronological change. And maybe for left-to-right readers to only way is older left - newer right > > Norbert > > Am 22.06.2017 um 03:40 schrieb Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: > >> Hi Guys - when you launch the Synchronize window in iceberg - is it me, or are the colour highlights backwards (and possibly the ordering of the panes)? >> >> If the left pane is my working copy, and I've added some code to a method - why does it appear in red on the left (which typically means deleted?). I notice that in IntelliJ (and other tools) your working changes are typically on the right and things you add are in Green on that right hand side. >> >> I think that ordering and colour coding make more sense - from -> to, and red is deleted, green is added. >> >> Of course I can live with the different pane ordering, but I think the colours might be wrong? >> >> Tim

June 22, 2017