July 2016 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Spec vs Brick vs Glamour vs Morphic vs WTF?

by Brad Selfridge

Thank you all for your responses. I have to admit that I was really confused. I will start the process with Spec. ----- Brad Selfridge -- View this message in context: http://forum.world.st/Spec-vs-Brick-vs-Glamour-vs-Morphic-vs-WTF-tp4905178p… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 6, 2016

Re: [Pharo-users] [UFFI] Using a nested structure

by Merwan Ouddane

PS: for the first example, the alignment is not respected, the vec3 structure is starting at 9 but uffi is fetching it at 5 On 06/07/2016 17:55, Merwan Ouddane wrote: > Another test: > I replaced double by integer, for visibility... > typedef struct vec3 { > int data[3]; > } vec3; > > add a second vec3 to position: > > typedef struct position { > int i; > vec3 vec; > vec3 vec2; > } position; > > Now in pharo: > Position >> fieldsDesc > "self rebuildFieldAccessors" > ^ #( > int i; > Vec3 vec; > Vec3 vec2; > ) > > The size returned for each stucture is 16 instead of 12 that because > of the "8 byte alignment" > > Meaning that the "position" structure is corrupted. > > With this function: > > > extern "C" void DLL_EXPORT fillStruct(position *position) > { > position -> i = 19; > (position -> vec).data[0] = 1; > (position -> vec).data[1] = 2; > (position -> vec).data[2] = 3; > (position -> vec2).data[0] = 1; > (position -> vec2).data[1] = 2; > (position -> vec2).data[2] = 3; > } > > We will get: > position i == 19 > position vec at: 1 == 1 > position vec2 at: 1 == 2 > > > On Tue, Jul 5, 2016 at 3:12 PM, Ronie Salgado <roniesalg(a)gmail.com > <mailto:roniesalg@gmail.com>> wrote: > > I compiled the DLL using Visual Studio 2015 Community Edition. > Later I will check with mingw. > > 2016-07-05 14:58 GMT+02:00 Merwan Ouddane <merwanouddane(a)gmail.com > <mailto:merwanouddane@gmail.com>>: > > Using codeblocks, mine are: > > mingw32-g++.exe -m32 -DBUILD_DLL -c main.cpp -o obj\Release\main.o > mingw32-g++.exe -shared > -Wl,--output-def=bin\Release\libTest.def > -Wl,--out-implib=bin\Release\libTest.a -Wl,--dll > obj\Release\main.o -o bin\Release\Test.dll -s -m32 > > > On Tue, Jul 5, 2016 at 2:52 PM, Merwan Ouddane > <merwanouddane(a)gmail.com <mailto:merwanouddane@gmail.com>> wrote: > > I am not moving from another plateform :/ > > I tried it in pharo 6 and I it didn't work either. > > It could be my dll. What is your compilation line for the > dll ? > > Thanks you, > Merwan > > On Tue, Jul 5, 2016 at 2:14 PM, Ronie Salgado > <roniesalg(a)gmail.com <mailto:roniesalg@gmail.com>> wrote: > > Hi Merwan, > > I tested this on Pharo 6 and it is working in Windows. > However, in 32 bits Window doubles have an 8 byte > alignment, unlike Linux where they have a 4 byte > alignment. > > Can you try doing the following before performing the > ffi call in Windows, if you are moving an image from > Linux or OS X: > > Vec3 rebuildFieldAccessors. > Position rebuildFieldAccessors. > > Best regards, > Ronie > > 2016-07-05 11:11 GMT+02:00 Merwan Ouddane > <merwanouddane(a)gmail.com > <mailto:merwanouddane@gmail.com>>: > > Hi, > > I have an issue whith nested structures. > > I made some "dummy" structures in c: > > > typedef struct vec3 { > double data[3]; > } vec3; > > typedef struct position { > int i; > vec3 vec; > } position; > > And a "dummy" function to fill it: > void fillStruct(position *position) > { > position -> i = 19; > (position -> vec).data[0] = 1; > (position -> vec).data[1] = 2; > (position -> vec).data[2] = 3; > } > > But I can't make the nested structure work. > The "i" is correctly set to 19 but I have values > that doesn't make any sense in the vec3 structure. > > In Pharo > I declared the Double3 type for the array inside Vec3: > Double3 := FFITypeArray ofType: 'double' size: 3 > > Vec3>>fieldsDesc > ^ #( > Double3 v; > ) > > And the position: > Position>>fieldsDesc > ^ #( > int i; > Vec3 vec; > ) > > The ffi call: > ^ self ffiCall: #(void fillStruct(Position > *position)) module: 'Test.dll' > > Sorry for the long / messy mail :p > > Any clues ? > > Cheers, > Merwan > > > > > >

July 6, 2016

Re: [Pharo-users] Pharo Mooc

by Offray Vladimir Luna CÃ¡rdenas

Hi, Nice! I suggest to link the resources of the second link into the first one. We're going to make our usual Data Week at the end of July and we're going to start a Data Roda this week (think in a coding dojo, but with data visualization and capoeira :-P) and we' going to link these MOOOC resources with our usual practices. I'm now just finishing my MOOC's third week and the ReDo exercise for the DSL on D&D dice has been really clarifying. Having this MOOC resources linked to permanent community practices and places (local and global, like this list itself) will be one of the most important results of it. Cheers, Offray On 06/07/16 09:16, stepharo wrote: > > http://mooc.pharo.org :) > > > soon the videos will be available > > http://rmod-pharo-mooc.lille.inria.fr > > > > Le 6/7/16 Ã 14:00, Arie van Wingerden a Ã©crit : >> âHi, >> >> on the main Pharo page I see Pharo Mooc mentioned. Obviously I am too >> late to join. >> >> Will there be a similar course in the (near) future? >> >> Are there other (video) courses available? I checked Udemy and >> O'Reilly, but alas, Smalltalk isn't that popular anymore nowadays... >> >> Thx, >> Arie >

July 6, 2016

Re: [Pharo-users] Spec vs Brick vs Glamour vs Morphic vs WTF?

by Offray Vladimir Luna CÃ¡rdenas

Hi, Just to share my experience as a newbie with Pharo/Smalltalk and how I deal with the diversity of graphical toolkits, which in my case was pretty problem related. I want to create some kind of "app"[1][2] that used trees as structuring metaphor for interactive documents. The easiest way to program it was using Glamour and this gave me a quick functional prototype, but when I started to stretch the functionality even more Glamour, showed it limitations and in that case, spec and particularly Johan's spec-glamour bridge, has been really empowering for more general interfaces, without loosing the interactivity part given by GT playgrounds. Still there is a lot of work to be done and after finishing the Pharo MOOC I will be retaking my project again, but I would tell that spec is a solid toolkit and your choice doesn't need to be binary. You can start with one toolkit, like in my case and combine with other or refactor the code to migrate functionality. If you have enough time (for example don't have any rush for a quick & dirty prototype), I would advice to start with spec with the tranquility that it will be there in the time to come, and that the bindings with Glamour, Bloc, Brick and Morphic, will let you extent the interface when the need arises. [1] http://smalltalkhub.com/#!/~Offray/Grafoscopio [2] http://mutabit.com/grafoscopio/index.en.html Cheers, Offray On 06/07/16 11:11, Johan Fabry wrote: > Hi Brad, > > to clarify the situation: Spec is the standard UI framework for Pharo, and the plan is that it will stay this way. Morphic/Brick/Block/â¦ are (or will be) a layer underneath that, which ideally you would not need care about. > > The documentation of Spec is not up to date right now, and hard to find. But the good news is that I am working on it this very week (and next week). Please hang tight for a few more days, I will publicly release a work-in-progress documentation soon. For now, you can have a look at the youtube video of my presentation at the Pharo days 2 years ago: https://www.youtube.com/watch?v=OL23s9ZUIR0 it should already point you in the right direction. > > -- > Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org . > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > >> On Jul 6, 2016, at 11:14, Brad Selfridge <bsselfridge(a)gmail.com> wrote: >> >> So, once Brick/Bloc become public, will it become the default UI framework? >> What happens to Spec and Glamour when/if that happens? >> >> >> >> ----- >> Brad Selfridge >> -- >> View this message in context: http://forum.world.st/Spec-vs-Brick-vs-Glamour-vs-Morphic-vs-WTF-tp4905178p… >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >> >> > >

July 6, 2016

Re: [Pharo-users] Spec vs Brick vs Glamour vs Morphic vs WTF?

by Johan Fabry

Hi Brad, to clarify the situation: Spec is the standard UI framework for Pharo, and the plan is that it will stay this way. Morphic/Brick/Block/â¦ are (or will be) a layer underneath that, which ideally you would not need care about. The documentation of Spec is not up to date right now, and hard to find. But the good news is that I am working on it this very week (and next week). Please hang tight for a few more days, I will publicly release a work-in-progress documentation soon. For now, you can have a look at the youtube video of my presentation at the Pharo days 2 years ago: https://www.youtube.com/watch?v=OL23s9ZUIR0 it should already point you in the right direction. -- Does this mail seem too brief? Sorry for that, I donât mean to be rude! Please see http://emailcharter.org . Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile > On Jul 6, 2016, at 11:14, Brad Selfridge <bsselfridge(a)gmail.com> wrote: > > So, once Brick/Bloc become public, will it become the default UI framework? > What happens to Spec and Glamour when/if that happens? > > > > ----- > Brad Selfridge > -- > View this message in context: http://forum.world.st/Spec-vs-Brick-vs-Glamour-vs-Morphic-vs-WTF-tp4905178p… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

July 6, 2016

Re: [Pharo-users] a bug in Spec that I wont fix

by Ben Coman

On Wed, Jul 6, 2016 at 11:42 PM, Hartmut Krasemann <Hartmut.Krasemann(a)t-online.de> wrote: > Hi to whom it concerns. > > Working with Spec (Pharo 4.0) I needed to dynamically update the ButtonModel > BalloonHelp. > Since it did not work, I searched and found that ButtonModel initializes > helpHolder again thus removing the changeBlock set in AbstractWidgetModel. > > The statement < helpHolder := nil asValueHolder. > in > ButtonModel>>initialize has to be removed. > > Since I do not yet work with Pharo 5 I propose that somebody working with > Pharo 5 would fix this. Hi Hartmut, Thanks for your report. Could you add this to our issue tracker https://pharo.fogbugz.com/default.asp?W41 and hopefully could you include some code in the form of a test that fails before your change and succeeds afterwards (like checking whether the value of helpHolder is nil or not) cheers -ben

July 6, 2016

Re: [Pharo-users] [UFFI] Using a nested structure

by Merwan Ouddane

Another test: I replaced double by integer, for visibility... typedef struct vec3 { int data[3]; } vec3; add a second vec3 to position: typedef struct position { int i; vec3 vec; vec3 vec2; } position; Now in pharo: Position >> fieldsDesc "self rebuildFieldAccessors" ^ #( int i; Vec3 vec; Vec3 vec2; ) The size returned for each stucture is 16 instead of 12 that because of the "8 byte alignment" Meaning that the "position" structure is corrupted. With this function: extern "C" void DLL_EXPORT fillStruct(position *position) { position -> i = 19; (position -> vec).data[0] = 1; (position -> vec).data[1] = 2; (position -> vec).data[2] = 3; (position -> vec2).data[0] = 1; (position -> vec2).data[1] = 2; (position -> vec2).data[2] = 3; } We will get: position i == 19 position vec at: 1 == 1 position vec2 at: 1 == 2 On Tue, Jul 5, 2016 at 3:12 PM, Ronie Salgado <roniesalg(a)gmail.com> wrote: > I compiled the DLL using Visual Studio 2015 Community Edition. Later I > will check with mingw. > > 2016-07-05 14:58 GMT+02:00 Merwan Ouddane <merwanouddane(a)gmail.com>: > >> Using codeblocks, mine are: >> >> mingw32-g++.exe -m32 -DBUILD_DLL -c main.cpp -o obj\Release\main.o >> mingw32-g++.exe -shared -Wl,--output-def=bin\Release\libTest.def >> -Wl,--out-implib=bin\Release\libTest.a -Wl,--dll obj\Release\main.o -o >> bin\Release\Test.dll -s -m32 >> >> >> On Tue, Jul 5, 2016 at 2:52 PM, Merwan Ouddane <merwanouddane(a)gmail.com> >> wrote: >> >>> I am not moving from another plateform :/ >>> >>> I tried it in pharo 6 and I it didn't work either. >>> >>> It could be my dll. What is your compilation line for the dll ? >>> >>> Thanks you, >>> Merwan >>> >>> On Tue, Jul 5, 2016 at 2:14 PM, Ronie Salgado <roniesalg(a)gmail.com> >>> wrote: >>> >>>> Hi Merwan, >>>> >>>> I tested this on Pharo 6 and it is working in Windows. However, in 32 >>>> bits Window doubles have an 8 byte alignment, unlike Linux where they have >>>> a 4 byte alignment. >>>> >>>> Can you try doing the following before performing the ffi call in >>>> Windows, if you are moving an image from Linux or OS X: >>>> >>>> Vec3 rebuildFieldAccessors. >>>> Position rebuildFieldAccessors. >>>> >>>> Best regards, >>>> Ronie >>>> >>>> 2016-07-05 11:11 GMT+02:00 Merwan Ouddane <merwanouddane(a)gmail.com>: >>>> >>>>> Hi, >>>>> >>>>> I have an issue whith nested structures. >>>>> >>>>> I made some "dummy" structures in c: >>>>> >>>>> >>>>> typedef struct vec3 { >>>>> double data[3]; >>>>> } vec3; >>>>> >>>>> typedef struct position { >>>>> int i; >>>>> vec3 vec; >>>>> } position; >>>>> And a "dummy" function to fill it: >>>>> void fillStruct(position *position) >>>>> { >>>>> position -> i = 19; >>>>> (position -> vec).data[0] = 1; >>>>> (position -> vec).data[1] = 2; >>>>> (position -> vec).data[2] = 3; >>>>> } >>>>> >>>>> But I can't make the nested structure work. >>>>> The "i" is correctly set to 19 but I have values that doesn't make any >>>>> sense in the vec3 structure. >>>>> >>>>> In Pharo >>>>> I declared the Double3 type for the array inside Vec3: >>>>> Double3 := FFITypeArray ofType: 'double' size: 3 >>>>> >>>>> Vec3>>fieldsDesc >>>>> ^ #( >>>>> Double3 v; >>>>> ) >>>>> >>>>> And the position: >>>>> Position>>fieldsDesc >>>>> ^ #( >>>>> int i; >>>>> Vec3 vec; >>>>> ) >>>>> >>>>> The ffi call: >>>>> ^ self ffiCall: #(void fillStruct(Position *position)) module: >>>>> 'Test.dll' >>>>> >>>>> Sorry for the long / messy mail :p >>>>> >>>>> Any clues ? >>>>> >>>>> Cheers, >>>>> Merwan >>>>> >>>> >>>> >>> >> >

July 6, 2016

a bug in Spec that I wont fix

by Hartmut Krasemann

Hi to whom it concerns. Working with Spec (Pharo 4.0) I needed to dynamically update the ButtonModel BalloonHelp. Since it did not work, I searched and found that ButtonModel initializes helpHolder again thus removing the changeBlock set in AbstractWidgetModel. The statement < helpHolder := nil asValueHolder. > in ButtonModel>>initialize has to be removed. Since I do not yet work with Pharo 5 I propose that somebody working with Pharo 5 would fix this. Thanks -- signatur Hartmut Krasemann KÃ¶nigsberger Str. 41 c D 22869 Schenefeld Tel. 040.8307097 Mobil 0171.6451283 Krasemann(a)acm.org

July 6, 2016

Re: [Pharo-users] Spec vs Brick vs Glamour vs Morphic vs WTF?

by Brad Selfridge

So, once Brick/Bloc become public, will it become the default UI framework? What happens to Spec and Glamour when/if that happens? ----- Brad Selfridge -- View this message in context: http://forum.world.st/Spec-vs-Brick-vs-Glamour-vs-Morphic-vs-WTF-tp4905178p… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 6, 2016

Re: [Pharo-users] Spec vs Brick vs Glamour vs Morphic vs WTF?

by Cyril Ferlicot Delbecque

On 06/07/2016 15:43, Brad Selfridge wrote: > Ok! I'm really confused. I'm wanting to write new GUI and I have no idea > which framework to use. There is very little documentation on any of these > and I don't see a clear cut statement of direction as to where the Pharo > community is heading. > > Can someone please advise? > > Thanks. > > Hi, >From what I know: Morphic is the low level layer behind GUI in Pharo. Since this is low level there is usually some framework on top for users to use. Spec is a framework to build GUI. Brick is a work in progress. There is a project call Bloc that will replace Morphic in the future. Brick is a layer on top of Bloc to build widgets on top of Bloc. Glamour is good to use if you work a lot with some flux of data. Each elements of a Glamour panel will be feed by data from another element. It is good to use when you have, for example, elements to update on a list selection or thing like that. I hope this will help you to make your choice. So Morphic will vanish in few years. Bloc and brick will replace it. I think there is a Moose book with a Glamour chapter. And the community is writing a book on spec I think. > > ----- > Brad Selfridge > -- > View this message in context: http://forum.world.st/Spec-vs-Brick-vs-Glamour-vs-Morphic-vs-WTF-tp4905178.… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

July 6, 2016