November 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo TechTalk 21 Nov: Discord Demo

by Juraj Kubelka

> On Nov 21, 2017, at 21:57, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Juraj Kubelka wrote >> the TechTalk record is available at the same link: >> https://www.youtube.com/watch?v=33kXsOiP6wA > > Thanks! The quality seems to top out at 480p, which is pretty blurry. It > makes the code nearly unreadable. Any way to bump the resolution on the next > one? I do not know how to improve the streaming itself. Maybe the internet speed was not perfect that day in Chile. I will upload recording I have on my computer. It is clear. Cheers, Juraj > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Nov. 22, 2017

Re: [Pharo-dev] Advent of code

by Stephane Ducasse

Julien could you open a github project so that we can do the same as norviq? And get a log of the problems and solution? Stef On Wed, Nov 22, 2017 at 2:25 PM, Serge Stinckwich < serge.stinckwich(a)gmail.com> wrote: > BTW, the Japanese Smalltalk community is doing an advent Calendar every > year: > > https://qiita.com/advent-calendar/2016/smalltalk > > The 2017 edition is in preparation here: https://qiita.com/advent- > calendar/2017/smalltalk > > > > On Wed, Nov 22, 2017 at 1:29 PM, Stephane Ducasse <stepharo.self(a)gmail.com > > wrote: > >> Hi pharoers >> >> I would like to know if you would like to participate to >> http://adventofcode.com/2016 >> >> For example we could do the same as >> https://github.com/norvig/pytudes/blob/master/ipynb/Advent% >> 20of%20Code.ipynb >> >> Stef >> >> > > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC/UY1) > "Programs must be written for people to read, and only incidentally for > machines to execute."http://www.doesnotunderstand.org/ >

Nov. 22, 2017

Re: [Pharo-dev] Problem with primitive instVarAt: / instVarAt:put:, what should we do ?

by ClÃ©ment Bera

On Wed, Nov 22, 2017 at 3:34 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hi. > > Just to notice: it is here long time (I checked Pharo 1 and current > Squeak). > > Probably some Spur changes to integrate in the image then. > > 2017-11-22 14:35 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > >> Hi All, >> >> It seems Pharo is lacking the slotAt: / slotAt:put: primitive and that >> the instVarAt: / instVarAt:put: primitive is not doing what it says it >> does. When I look at Object>>#instVarAt: I see: >> >> "[...]Answer a fixed variable in an object. The numbering of the variables >> corresponds to the named instance variables, followed by the indexed >> instance >> variables. Fail if the index is not an Integer or is not the index of a >> fixed variable[...]" >> >> Now in Pharo 7 when one does: >> >> #(iv1) instVarAt: 1, one gets #iv1. >> >> So the comment is wrong. >> >> The reason for this is that instVarAt: / instVarAt:put: should be >> primitive 73/74, while they are in Pharo 173/174 (primitive >> slotAt:/slotAt:put:). The slot primitive access pointer slots of objects, >> whichever inst var or variable fields. A good example would be: >> >> | t | >> t := #temp. >> [ t ] instVarAt: 4, one gets #temp >> >> So I have two solutions for this problem: >> 1) We change the instVarAt: / instVarAt:put: primitives comments to match >> the slotAt: / slotAt:put: behavior, and in Pharo instVarAt: / >> instVarAt:put: means in factslotAt: / slotAt:put: . >> 2) We change the instVarAt: / instVarAt:put: primitives to primitive 73 >> and 74, we introduce slotAt: / slotAt:put: with primitive 173/174 and we >> ask everyone to fix their code relying on instVarAt: / instVarAt:put: >> acting as slotAt: / slotAt:put: >> > > I prefer explicit behaviour. These methods have clear intention in names: > inst var accessing. It should be error when given index is out of #instSize > range. > > For new methods I would not use slot based naming because slots in Pharo > is already something more then just object fields. > Maybe #fieldAt:, #fieldAt:put: would be good? And also #fieldSize for > consistency > fieldSize is not a primitive in this case, Object>>#fieldSize ^ self class instSize + self basicSize > >> >> What do you think ? >> >> Best, >> >> >> -- >> ClÃ©ment BÃ©ra >> Pharo consortium engineer >> https://clementbera.wordpress.com/ >> BÃ¢timent B 40, avenue Halley 59650 >> <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g>Villeneuve >> d >> <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g> >> 'Ascq >> <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g> >> > > -- ClÃ©ment BÃ©ra Pharo consortium engineer https://clementbera.wordpress.com/ BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Nov. 22, 2017

[ANN] Smalltalks 2017 - Videos + Slides + Photos

by Gabriel Cotelli

Nov. 22, 2017

Re: [Pharo-dev] Problem with primitive instVarAt: / instVarAt:put:, what should we do ?

by Denis Kudriashov

Hi. Just to notice: it is here long time (I checked Pharo 1 and current Squeak). 2017-11-22 14:35 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > Hi All, > > It seems Pharo is lacking the slotAt: / slotAt:put: primitive and that the > instVarAt: / instVarAt:put: primitive is not doing what it says it does. > When I look at Object>>#instVarAt: I see: > > "[...]Answer a fixed variable in an object. The numbering of the variables > corresponds to the named instance variables, followed by the indexed > instance > variables. Fail if the index is not an Integer or is not the index of a > fixed variable[...]" > > Now in Pharo 7 when one does: > > #(iv1) instVarAt: 1, one gets #iv1. > > So the comment is wrong. > > The reason for this is that instVarAt: / instVarAt:put: should be > primitive 73/74, while they are in Pharo 173/174 (primitive > slotAt:/slotAt:put:). The slot primitive access pointer slots of objects, > whichever inst var or variable fields. A good example would be: > > | t | > t := #temp. > [ t ] instVarAt: 4, one gets #temp > > So I have two solutions for this problem: > 1) We change the instVarAt: / instVarAt:put: primitives comments to match > the slotAt: / slotAt:put: behavior, and in Pharo instVarAt: / > instVarAt:put: means in factslotAt: / slotAt:put: . > 2) We change the instVarAt: / instVarAt:put: primitives to primitive 73 > and 74, we introduce slotAt: / slotAt:put: with primitive 173/174 and we > ask everyone to fix their code relying on instVarAt: / instVarAt:put: > acting as slotAt: / slotAt:put: > I prefer explicit behaviour. These methods have clear intention in names: inst var accessing. It should be error when given index is out of #instSize range. For new methods I would not use slot based naming because slots in Pharo is already something more then just object fields. Maybe #fieldAt:, #fieldAt:put: would be good? And also #fieldSize for consistency > > What do you think ? > > Best, > > > -- > ClÃ©ment BÃ©ra > Pharo consortium engineer > https://clementbera.wordpress.com/ > BÃ¢timent B 40, avenue Halley 59650 > <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g>Villeneuve > d > <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g> > 'Ascq > <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g> >

Nov. 22, 2017

Re: [Pharo-dev] [Vm-dev] FFI Struct Argument Pass By Value Fails on Mac 64 bit

by Ben Coman

On 22 November 2017 at 13:38, Todd Blanchard <tblanchard(a)mac.com> wrote: > > I've been trying to track this down for a couple weeks now. > > I have concluded that structs passed by value to functions on the 64 bit > VM are not properly populated. The struct's memory is all zero'd. > > I found this while trying to work with LibClang and found that functions > that fetched code locations from code ranges always returned invalid zero'd > locations. After spending some time with lldb I have traced the problem > into the native code and found that the argument is not correct. > > I've carved out the wee bit of clang to reproduce this in a tiny library. > > The gist of it is below and the entire file is included. Basically the > struct passed to the function clang_getRangeStart is zero'd memory > regardless of the data I send from the image side. > > The build command I used on sierra is clang -shared -undefined > dynamic_lookup -o microclang.dylib microclang.c > On Ubuntu 16.04 I used... $ clang -shared -fPIC -o libmicroclang.so microclang.c $ clang test.c -L. -l microclang test.c:6:53: error: no member named 'begin_int_data' in 'CXSourceLocation' if(clang_getRangeStart(clang_getArbitraryRange()).begin_int_data == 0) I presume you meant... if(clang_getRangeStart(clang_getArbitraryRange()).int_data == 0) so correcting and continuing... $ clang test.c -L. -l microclang $ LD_LIBRARY_PATH=. ./a.out That failed So I'm not sure how to proceed. I was expecting that would work while Pharo failed. Now interestingly... $ clang test.c microlang.c $ ./a.out That worked So it seems a similar problem exists outside our FFI. cheers -ben P.S. I refactored you code to extract a header file (attached) > I'm stuck. The FFI64 plugin is way beyond my comprehension. > > // microclang.c > > typedef struct { > const void *ptr_data[2]; > unsigned int_data; > } CXSourceLocation; > > /** > * \brief Identifies a half-open character range in the source code. > * > * Use clang_getRangeStart() and clang_getRangeEnd() to retrieve the > * starting and end locations from a source range, respectively. > */ > typedef struct { > const void *ptr_data[2]; > unsigned begin_int_data; > unsigned end_int_data; > } CXSourceRange; > > const char* first = "first_pointer"; > const char* second = "second_pointer"; > > // return a fake range with non zero data > CXSourceRange clang_getArbitraryRange() > { > CXSourceRange range = {0}; > range.ptr_data[0] = (void*)first; > range.ptr_data[1] = (void*)second; > range.begin_int_data = 17; > range.end_int_data = 24; > return range; > } > > // Actual clang function - range is always zero'd here despite having > values in the image > CXSourceLocation clang_getRangeStart(CXSourceRange range) { > // Special decoding for CXSourceLocations for CXLoadedDiagnostics. > if ((uintptr_t)range.ptr_data[0] & 0x1) { > CXSourceLocation Result = { { range.ptr_data[0], nullptr }, 0 }; > return Result; > } > > > CXSourceLocation Result = { { range.ptr_data[0], range.ptr_data[1] }, > range.begin_int_data }; > return Result; > } >

Nov. 22, 2017

Problem with primitive instVarAt: / instVarAt:put:, what should we do ?

by ClÃ©ment Bera

Hi All, It seems Pharo is lacking the slotAt: / slotAt:put: primitive and that the instVarAt: / instVarAt:put: primitive is not doing what it says it does. When I look at Object>>#instVarAt: I see: "[...]Answer a fixed variable in an object. The numbering of the variables corresponds to the named instance variables, followed by the indexed instance variables. Fail if the index is not an Integer or is not the index of a fixed variable[...]" Now in Pharo 7 when one does: #(iv1) instVarAt: 1, one gets #iv1. So the comment is wrong. The reason for this is that instVarAt: / instVarAt:put: should be primitive 73/74, while they are in Pharo 173/174 (primitive slotAt:/slotAt:put:). The slot primitive access pointer slots of objects, whichever inst var or variable fields. A good example would be: | t | t := #temp. [ t ] instVarAt: 4, one gets #temp So I have two solutions for this problem: 1) We change the instVarAt: / instVarAt:put: primitives comments to match the slotAt: / slotAt:put: behavior, and in Pharo instVarAt: / instVarAt:put: means in factslotAt: / slotAt:put: . 2) We change the instVarAt: / instVarAt:put: primitives to primitive 73 and 74, we introduce slotAt: / slotAt:put: with primitive 173/174 and we ask everyone to fix their code relying on instVarAt: / instVarAt:put: acting as slotAt: / slotAt:put: What do you think ? Best, -- ClÃ©ment BÃ©ra Pharo consortium engineer https://clementbera.wordpress.com/ BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Nov. 22, 2017

Re: [Pharo-dev] Advent of code

by Serge Stinckwich

BTW, the Japanese Smalltalk community is doing an advent Calendar every year: https://qiita.com/advent-calendar/2016/smalltalk The 2017 edition is in preparation here: https://qiita.com/advent-calendar/2017/smalltalk On Wed, Nov 22, 2017 at 1:29 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi pharoers > > I would like to know if you would like to participate to > http://adventofcode.com/2016 > > For example we could do the same as > https://github.com/norvig/pytudes/blob/master/ipynb/ > Advent%20of%20Code.ipynb > > Stef > > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."http://www.doesnotunderstand.org/

Nov. 22, 2017

Re: [Pharo-dev] Advent of code

by Julien

The 2017 version will be online on 1st December normally. I will participate for sure, I implemented some of the algorithms of 2016 versions and Iâd say that Pharo is really cool to do that because of its nice Collections framework (a lot of exercises are about extracting data from/transforming/interpret data-structures provided serialised in a text file). :-) Julien > Le 22 nov. 2017 Ã 13:29, Stephane Ducasse <stepharo.self(a)gmail.com> a Ã©crit : > > Hi pharoers > > I would like to know if you would like to participate to > http://adventofcode.com/2016 > > For example we could do the same as > https://github.com/norvig/pytudes/blob/master/ipynb/Advent%20of%20Code.ipynb > > Stef >

Nov. 22, 2017

[Pharo 7.0-dev] Build #317: 20645-Windows-rebuildFieldAccessors-problem

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #317 was: SUCCESS. The Pull Request #521 was integrated: "20645-Windows-rebuildFieldAccessors-problem" Pull request url: https://github.com/pharo-project/pharo/pull/521 Issue Url: https://pharo.fogbugz.com/f/cases/20645 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 22, 2017