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

Re: [Pharo-users] A Management Software Building Library in Pharo

by Alexandre Bergel

There is roassal if you need to visualize data. I have seen people visualizing relations between software artifacts. Alexandre > On Jul 11, 2016, at 2:32 AM, Lionel Akue <lionelakue(a)gmail.com> wrote: > > Hi > > I am making a library to accelerate the building of management software. > > I am looking for existing libraries: > > for UI. (I know Seaside and Morphic) > for persistence (I know Garage, Voyage) > other tools(I know Magritte for object descriptions) > > Thanks for sharing other libraries you know about. Any other informations are welcomed. > > Lionel > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

July 11, 2016

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

by Esteban Lorenzano

Hi, I uploaded the fix for it. it will be integrated soon. Esteban > On 11 Jul 2016, at 13:13, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > > The alignment calculation of external enums is wrong, it should be > > FFIExternalEnumerationType >> externalTypeAlignment > ^ self representationType externalTypeAlignment > > It only manifests for 32bit platforms on Windows since that's the only one with a pointer alignment (which superclass FFIExternalReferenceType returns) of 8, not 4 (which is the same alignment as the correct FFIUInt alignment) > > Cheers, > Henry > > >> On 09 Jul 2016, at 12:08 , Merwan Ouddane <merwanouddane(a)gmail.com <mailto:merwanouddane@gmail.com>> wrote: >> >> Yes I did. >> >> Have you tried on windows ? >> >> Merwan >> >> On 08/07/2016 21:20, Esteban Lorenzano wrote: >>> it works fine for me: >>> >>> Struct>>b >>> "This method was automatically generated" >>> ^Enum fromInteger: (handle unsignedLongAt: 5) >>> >>> Struct>>b: anObject >>> "This method was automatically generated" >>> handle unsignedLongAt: 5 put: anObject value >>> >>> Struct>>c >>> "This method was automatically generated" >>> ^Enum fromInteger: (handle unsignedLongAt: 9) >>> >>> Struct>>c: anObject >>> "This method was automatically generated" >>> handle unsignedLongAt: 9 put: anObject value >>> >>> question: did you initialise the Enum? before generating fields? >>> >>> Esteban >>> >>>> On 08 Jul 2016, at 20:42, Merwan Ouddane <merwanouddane(a)gmail.com <mailto:merwanouddane@gmail.com>> wrote: >>>> >>>> Struct >> fieldsDesc >>>> ^#( void* a; >>>> Enum b; >>>> Enum c; >>>> ) >>>> >>>> Enum >> enumDecl >>>> ^ #( TEST 1 ) >>>> >>>> I joined a .st with the struct and the enum, the package name is FFITest. >>>> >>>> Merwan >>>> >>>> On 08/07/2016 20:14, Esteban Lorenzano wrote: >>>>> that still does not helpsâ¦ show me the code! >>>>> >>>>> Esteban >>>>> >>>>>> On 08 Jul 2016, at 20:09, Merwan Ouddane <merwanouddane(a)gmail.com <mailto:merwanouddane@gmail.com>> wrote: >>>>>> >>>>>> Sorry not unsigned longs but enumerations >>>>>> >>>>>> On Fri, Jul 8, 2016 at 10:09 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>>>>> how do you declare this? >>>>>> >>>>>>> On 08 Jul 2016, at 10:01, Merwan Ouddane <merwanouddane(a)gmail.com <mailto:merwanouddane@gmail.com>> wrote: >>>>>>> >>>>>>> I spoke too fast ^^' >>>>>>> >>>>>>> struct Test { >>>>>>> void * ptr; >>>>>>> insigned long i; >>>>>>> insigned long j; >>>>>>> } >>>>>>> >>>>>>> Real size is 12, UFFI counts 24 >>>>>>> >>>>>>> Merwan >>>>>>> >>>>>>> >>>>>>> Le 7 juil. 2016 10:02, "Merwan Ouddane" <merwanouddane(a)gmail.com <mailto:merwanouddane@gmail.com>> a Ã©crit : >>>>>>> Now it is working, thank you :) >>>>>>> >>>>>>> On Thu, Jul 7, 2016 at 8:42 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>>>>>> Hi, >>>>>>> >>>>>>> > On 07 Jul 2016, at 01:54, Ben Coman <btc(a)openInWorld.com <mailto:btc@openinworld.com>> wrote: >>>>>>> > >>>>>>> > On Thu, Jul 7, 2016 at 12:58 AM, Merwan Ouddane <merwanouddane(a)gmail.com <mailto:merwanouddane@gmail.com>> wrote: >>>>>>> >> PS: for the first example, the alignment is not respected, the vec3 >>>>>>> >> structure is starting at 9 but uffi is fetching it at 5 >>>>>>> > >>>>>>> > Hi Esteban, >>>>>>> > >>>>>>> > Is it possible to get a feature or a recipe to output the sizeof or >>>>>>> > offset of fields in types as understood by the Image, and the same >>>>>>> > from a C side - that could be used as the standard first step in >>>>>>> > troubleshooting these kinds of issues ? >>>>>>> >>>>>>> FFIExternalType class>>sizeOf: ? >>>>>>> >>>>>>> but that does not works for complex type sizes (like FFIExternalArray). >>>>>>> >>>>>>> I donât know what the problem is here, because in my test (attached) it seems to be working fine. >>>>>>> maybe problem is on how the Vec3 array is created, it should be something like this: >>>>>>> >>>>>>> Vec3 class>>iinitialize >>>>>>> self >>>>>>> type: (FFIExternalType resolveType: 'double') >>>>>>> size: 3 >>>>>>> >>>>>>> (is like that because FFITypeArray is more designed to be used creating anonymous types than concretes, but wellâ¦ ) >>>>>>> >>>>>>> in any case, it seems to be working for me. >>>>>>> >>>>>>> Now, about the useâ¦ >>>>>>> >>>>>>> doing this: >>>>>>> >>>>>>> p := Position new. >>>>>>> p v1 at: 1 put: 42.0. >>>>>>> p v1 at: 1. âwill print 0.0" >>>>>>> >>>>>>> why? because it works making a copy (maybe it should work passing a segment, as nested structs work, but this is how it works now). >>>>>>> >>>>>>> What should work (at doesnât) in this case is this: >>>>>>> >>>>>>> v := Vector3 new. >>>>>>> p := Position new. >>>>>>> v at: 1 put: 42.0. >>>>>>> p v1: v. >>>>>>> p v1 at: 1. âwill print 42.0" >>>>>>> >>>>>>> it does not work because I made a mistake in field generation that I already fixedâ¦ so you will need to update UFFI (and regenerate field accessors) ;) >>>>>>> >>>>>>> alsoâ¦ I will provide a fix to make first case workâ¦ just later because now Iâm going to my french lessons :) >>>>>>> >>>>>>> Esteban >>>>>>> >>>>>>> ps: for future reference, a description of: install this, run that, is a lot easier to understand the problem (is a case of âshow me the code!â) :P >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> > >>>>>>> > cheers -ben >>>>>>> > >>>>>>> >> >>>>>>> >> >>>>>>> >> 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 >>>>>>> >>>>>> >>>>>>> >>>>>> >>>>>>> >>>>> >>>>>>> >>>> >>>>>>> >>> >>>>>>> >> >>>>>>> >> >>>>>>> > >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> <FFITest.st <http://ffitest.st/>> >>> >> >

July 11, 2016

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

by Henrik Johansen

The alignment calculation of external enums is wrong, it should be FFIExternalEnumerationType >> externalTypeAlignment ^ self representationType externalTypeAlignment It only manifests for 32bit platforms on Windows since that's the only one with a pointer alignment (which superclass FFIExternalReferenceType returns) of 8, not 4 (which is the same alignment as the correct FFIUInt alignment) Cheers, Henry > On 09 Jul 2016, at 12:08 , Merwan Ouddane <merwanouddane(a)gmail.com> wrote: > > Yes I did. > > Have you tried on windows ? > > Merwan > > On 08/07/2016 21:20, Esteban Lorenzano wrote: >> it works fine for me: >> >> Struct>>b >> "This method was automatically generated" >> ^Enum fromInteger: (handle unsignedLongAt: 5) >> >> Struct>>b: anObject >> "This method was automatically generated" >> handle unsignedLongAt: 5 put: anObject value >> >> Struct>>c >> "This method was automatically generated" >> ^Enum fromInteger: (handle unsignedLongAt: 9) >> >> Struct>>c: anObject >> "This method was automatically generated" >> handle unsignedLongAt: 9 put: anObject value >> >> question: did you initialise the Enum? before generating fields? >> >> Esteban >> >>> On 08 Jul 2016, at 20:42, Merwan Ouddane <merwanouddane(a)gmail.com <mailto:merwanouddane@gmail.com>> wrote: >>> >>> Struct >> fieldsDesc >>> ^#( void* a; >>> Enum b; >>> Enum c; >>> ) >>> >>> Enum >> enumDecl >>> ^ #( TEST 1 ) >>> >>> I joined a .st with the struct and the enum, the package name is FFITest. >>> >>> Merwan >>> >>> On 08/07/2016 20:14, Esteban Lorenzano wrote: >>>> that still does not helpsâ¦ show me the code! >>>> >>>> Esteban >>>> >>>>> On 08 Jul 2016, at 20:09, Merwan Ouddane <merwanouddane(a)gmail.com <mailto:merwanouddane@gmail.com>> wrote: >>>>> >>>>> Sorry not unsigned longs but enumerations >>>>> >>>>> On Fri, Jul 8, 2016 at 10:09 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>>>> how do you declare this? >>>>> >>>>>> On 08 Jul 2016, at 10:01, Merwan Ouddane <merwanouddane(a)gmail.com <mailto:merwanouddane@gmail.com>> wrote: >>>>>> >>>>>> I spoke too fast ^^' >>>>>> >>>>>> struct Test { >>>>>> void * ptr; >>>>>> insigned long i; >>>>>> insigned long j; >>>>>> } >>>>>> >>>>>> Real size is 12, UFFI counts 24 >>>>>> >>>>>> Merwan >>>>>> >>>>>> >>>>>> Le 7 juil. 2016 10:02, "Merwan Ouddane" <merwanouddane(a)gmail.com <mailto:merwanouddane@gmail.com>> a Ã©crit : >>>>>> Now it is working, thank you :) >>>>>> >>>>>> On Thu, Jul 7, 2016 at 8:42 AM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>>>>> Hi, >>>>>> >>>>>> > On 07 Jul 2016, at 01:54, Ben Coman <btc(a)openInWorld.com <mailto:btc@openinworld.com>> wrote: >>>>>> > >>>>>> > On Thu, Jul 7, 2016 at 12:58 AM, Merwan Ouddane <merwanouddane(a)gmail.com <mailto:merwanouddane@gmail.com>> wrote: >>>>>> >> PS: for the first example, the alignment is not respected, the vec3 >>>>>> >> structure is starting at 9 but uffi is fetching it at 5 >>>>>> > >>>>>> > Hi Esteban, >>>>>> > >>>>>> > Is it possible to get a feature or a recipe to output the sizeof or >>>>>> > offset of fields in types as understood by the Image, and the same >>>>>> > from a C side - that could be used as the standard first step in >>>>>> > troubleshooting these kinds of issues ? >>>>>> >>>>>> FFIExternalType class>>sizeOf: ? >>>>>> >>>>>> but that does not works for complex type sizes (like FFIExternalArray). >>>>>> >>>>>> I donât know what the problem is here, because in my test (attached) it seems to be working fine. >>>>>> maybe problem is on how the Vec3 array is created, it should be something like this: >>>>>> >>>>>> Vec3 class>>iinitialize >>>>>> self >>>>>> type: (FFIExternalType resolveType: 'double') >>>>>> size: 3 >>>>>> >>>>>> (is like that because FFITypeArray is more designed to be used creating anonymous types than concretes, but wellâ¦ ) >>>>>> >>>>>> in any case, it seems to be working for me. >>>>>> >>>>>> Now, about the useâ¦ >>>>>> >>>>>> doing this: >>>>>> >>>>>> p := Position new. >>>>>> p v1 at: 1 put: 42.0. >>>>>> p v1 at: 1. âwill print 0.0" >>>>>> >>>>>> why? because it works making a copy (maybe it should work passing a segment, as nested structs work, but this is how it works now). >>>>>> >>>>>> What should work (at doesnât) in this case is this: >>>>>> >>>>>> v := Vector3 new. >>>>>> p := Position new. >>>>>> v at: 1 put: 42.0. >>>>>> p v1: v. >>>>>> p v1 at: 1. âwill print 42.0" >>>>>> >>>>>> it does not work because I made a mistake in field generation that I already fixedâ¦ so you will need to update UFFI (and regenerate field accessors) ;) >>>>>> >>>>>> alsoâ¦ I will provide a fix to make first case workâ¦ just later because now Iâm going to my french lessons :) >>>>>> >>>>>> Esteban >>>>>> >>>>>> ps: for future reference, a description of: install this, run that, is a lot easier to understand the problem (is a case of âshow me the code!â) :P >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> > >>>>>> > cheers -ben >>>>>> > >>>>>> >> >>>>>> >> >>>>>> >> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>> >>>>>> >>> >>>>>> >> >>>>>> >> >>>>>> > >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> <FFITest.st <http://ffitest.st/>> >> >

July 11, 2016

Re: [Pharo-users] Database band reports...

by Alistair Grant

On Mon, Jul 11, 2016 at 09:00:27AM +0200, anonyme wrote: > Ok, that's the response I imagined. So, I will use Jaspert report... But a > last question : Do you know is I could push a bouton into my Smalltalk > application and run a jasper report like this ? I think I could run any a > process from smalltalk source code... For Unixy platforms see OSSubprocess: Metacello new configuration: 'OSSubprocess'; repository: 'github://marianopeck/OSSubprocess:master/repository'; version: #stable; load. HTH, Alistair

July 11, 2016

Re: [Pharo-users] Database band reports...

by anonyme

Ok, that's the response I imagined. So, I will use Jaspert report... But a last question : Do you know is I could push a bouton into my Smalltalk application and run a jasper report like this ? I think I could run any a process from smalltalk source code... Thank you again ! Patrick Le 09/07/2016 Ã 15:33, Ben Coman a Ã©crit : > I had a poke around and couldn't find any API documentation. If you > can find this someone could give a more considered opinion. > > > > If you store your data in a relational database, perhaps you could use > a third party report generator like Pentaho or JasperReports[1]. I > believe these are designed to be bolted on to applications, so perhaps > they'll have a more accessible API. From Pharo you should be able to > use a REST based API [2] of Pentaho. It apparently does band reports > [3]. > > [1] http://www.innoventsolutions.com/comparison-matrix.html > [2] https://help.pentaho.com/Documentation/6.0/0R0/070 > [3] http://wiki.pentaho.com/display/Reporting/band > > Disclaimer - This is just info I found for curiosity. I haven't used > any of these. > > cheers -ben > > P.S. Band reports features like the table in [1] would be a great > addition to the Pharo ecosystem. > > On Sat, Jul 9, 2016 at 2:29 AM, anonyme <sitepublique(a)free.fr> wrote: >> Ok, thanks you for responses. A band report is more than a PDF generator... >> It's a queries manager with varaible management facilities : details queries >> connect to master query, and you can manage sub report bottlenek into other >> master reports. The band report generator has the ability to manage page >> organisation, and editor add text styled... I can't use samlltalk database >> without a good band report component. >> >> But argos band report displayed under look to be fine, if there is a >> possibility to use it with smaltalk... It looks like argos is a server. But >> what about interfaces with smalltalk ? >> >> cheers - Patrick >> >> >> >> Le 08/07/2016 Ã 16:08, Ben Coman a Ã©crit : >>> On Fri, Jul 8, 2016 at 5:45 PM, stepharo <stepharo(a)free.fr> wrote: >>>> Hi patrick >>>> >>>> What is a band report? >>> http://webhelp.evisions.com/HelpFiles/Argos/4.2/en/Content/10101001.html >>> >>> Sorry Patrick. Pharo has such a GUI report generator. But Artefact >>> seems to provide similar features via code... >>> >>> https://ci.inria.fr/pharo-contribution/view/Books/job/EnterprisePharoBook/l… >>> >>> cheers -ben >>> >>>> Did you check Artefact because you can generate pdf with Artefact. >>>> >>>> Stef >>>> >>>> >>>> >>>>> Hi, >>>>> >>>>> My previous message stayed without responses, so I published it agin... >>>>> I'm >>>>> looking for a database band report component. The goal is to build >>>>> quickly >>>>> a >>>>> PDF report from SQL requests. An exemple is Lazreport, this is a >>>>> tutorial >>>>> <http://wiki.lazarus.freepascal.org/LazReport_Tutorial> . >>>>> >>>>> >>>>> >>>>> -- >>>>> View this message in context: >>>>> http://forum.world.st/Database-band-reports-tp4905523.html >>>>> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >>>>> >>>>> >> >

July 11, 2016

A Management Software Building Library in Pharo

by Lionel Akue

Hi I am making a library to accelerate the building of management software. I am looking for existing libraries: for UI. (I know Seaside and Morphic) for persistence (I know Garage, Voyage) other tools(I know Magritte for object descriptions) Thanks for sharing other libraries you know about. Any other informations are welcomed. Lionel

July 11, 2016

Re: [Pharo-users] Failing to create a project on SmalltalkHub

by sergpro

Victor RENE wrote > http://smalltalkhub.com/#!/~VictorRene > > I am trying to create a project on Smalltalk hub to save progress on the > MOOC. > But it fails with "incorrect username or password", and i can not logout. > Okay, I can probably empty my browser cache but it's still incorrect > behavior. I've had the same problem. As people write in other topics - it's connected with over-caching this site. My solution was to use incognito mode of Chrome - login from scratch and project created just fine. WBR, Serg. -- View this message in context: http://forum.world.st/Failing-to-create-a-project-on-SmalltalkHub-tp4893308… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 10, 2016

Re: [Pharo-users] SQLite + Pharo

by Hilaire

Hi Esteban, What is exactly thread safe from the Pharo perspective? Is Sqlite library handling the conflict of access, and put on wait an access not possible at a given moment, or does it signal it is busy? In the later case handling a wait may be necessary. I'm planing to use sql to manage users, groups, etc, then Fuel for business model where concurrent access does not exist. About Sql use with Smalltalk, I was looking for examples of best practice, but I did not find much. Thanks Hilaire Le 10/07/2016 16:24, Esteban A. Maringolo a Ã©crit : > The SQLite shared library is thread safe by default, so you shouldn't > worry about that. -- Dr. Geo http://drgeo.eu

July 10, 2016

Re: [Pharo-users] SQLite + Pharo

by Esteban A. Maringolo

The SQLite shared library is thread safe by default, so you shouldn't worry about that. El jul. 9, 2016 7:50 AM, "Hilaire" <hilaire(a)drgeo.eu> escribiÃ³: > Le 09/07/2016 11:42, Pierce Ng a Ã©crit : > > > After making UDBCSQLite3 work with Glorp on Pharo 5, I've > decided/realized that > > I don't have time to maintain both it and NBSQLite3. I'm leaving > NBSQLite3 more > > or less as is, and continue to work on UDBCSQLite3. > > It is fine and your contribution is nice! > I am in the process of learning how to use sqlite3 (itself and with > Pharo) and it is coincidence my working image is Pharo4, but later it > will move to newer Pharo5. > > One question on the top of my head, is how you deal with concurrent > access to sqlite tables from seaside sessionS. > Is the solution as naive as a waiting loop for the database to become > accessible ? > > Thanks > > Hilaire > > -- > Dr. Geo > http://drgeo.eu > > >

July 10, 2016

Re: [Pharo-users] Saving to local git and "Loading all file names from http://...pharo5/inbox"

by Peter UhnÃ¡k

As this is a real nuisance, I might have a partial solution â remove the repos :) Apart from contributing to pharo (which is done in clean images) I never needed reference to those repositories, so I don't see why I would need them there. So a startup script to the rescue StartupPreferencesLoader default executeAtomicItems: { StartupAction name: 'remove references to Pharo50 and Pharo50Inbox' code: [ |rx group| rx := '([0-9]{5})' asRegex. (rx matchesPrefix: Smalltalk image shortImageName) ifFalse: [ group := MCRepositoryGroup default. group repositories detect: [ :each | each location includesSubstring: 'Pharo/Pharo50Inbox/main' ] ifFound: [ :repo | group removeRepository: repo ]. "This repo is added twice for whatever reason (once main and once main/ or whatever." group repositories detect: [ :each | each location includesSubstring: 'Pharo/Pharo50/main' ] ifFound: [ :repo | group removeRepository: repo ]. group repositories detect: [ :each | each location includesSubstring: 'Pharo/Pharo50/main' ] ifFound: [ :repo | group removeRepository: repo ] ] ] runOnce: true. } Peter On Fri, Jun 3, 2016 at 8:49 PM, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > > > On 6/3/16 2:43 AM, Otto Behrens wrote: > > For FileTree repos it is even better to just load the package (Monticello > does a good job of only loading the changed packages and we're looking at > packages already on disk) ... ... I have an extension to Metacello for > Filetree repos (it's only been around for about 3 years) that ignores > version numbers and "loads" all of the packages from the the repo (I > mentioned _this_ to Thierry:) ... which for FileTree repos is actually the > proper behavior ... I happen to be very busy at the moment so I don't have > time to blow the dust off of that extension ... the big gotcha is everyone > has to have the extension present in their image for this kind of thing to > work and AFAIK pharo is not kept up-to-date with the latest versions that I > publish on github, so I'm afraid that much breakage would ensure if only a > few individuals started using this extension ... Seems to be that we're > stuck between a rock and a had place... I wish there was a better way to > keep the Metacello distribution up-to-date in images that I have no control > over ... > > FWIW, I've found that if I manually flush the cache for each package before > I save it, I don't have to wait the minute or so for all of the repos to be > refreshed ... > > Dale, will you please publish this stuff somewhere, with dust on, as > is? (Or tell us where we can find it). > > Well let's see there's the Metacello-Cypress package is in the Metacello > repo[1] and the following should load the Cypress support into an image > with Metacello already loaded: > > Metacello image > baseline: 'Metacello'; > load: ' Cypress' > > To use the Cypress support, implement a #projectClass method in your > BaselineOf that returns MetacelloCypressBaselineProject: > > projectClass > ^MetacelloCypressBaselineProject > > and you should be in business ... > > IIRC the MetacelloCypressBaselineProject should be usable with any > BaselineOf. The only difference for Cypress is that Monticello versions are > ignored when making loading decisions --- at least that's the intent. > > Before going full scale, we'd need to add some tests for the Cypress > project and of course make sure that the Cypress support gets loaded by > default ... > > [1] > https://github.com/dalehenrich/metacello-work/tree/master/repository/Metace… > > We've just battled sooo much in this area. I wonder if it is worth it > to think again about this whole git / monticello / metacello thing. > For me, it's just too much to comprehend. As soon as I dig into > something here, I get lost within minutes. > > I believe the complexity has to do with trying to maintain too many > different ways of solving the problem. We are trying to keep things > (Monticello / Metacello) working with or without git or filetree or > whatever else people are using. > > I would really like to do merging in git and just have a fast and > simple way of loading / compiling into an image (and GemStone). I do > not want a package cache, 3 way merging and all the other things, > because it makes what I end up with unpredictable. But you see, other > people want to work in other ways, which I understand. My perception > is that the result is messy. > > We should try to strive more towards *fewer* ways of doing things, > without killing innovation to try different ways. It feels as if there > are enormous, yet very incomplete silos of efforts to solve problems. > > > I basically agree with everything you say here. > > I added the Cypress package support several years ago when Richard Sargent > wrote a Cypress implementation for the base GemStone[2], so we've had the > bits a pieces necessary for a cleaner simpler mechanism for a while at > least for GemStone ... > > I would like to distinguish between Cypress and FileTree. > > FileTree was created (by you:) to support disk-based repos while > maintaining full Monticello compatibility. Over the years I've (stubbornly) > maintained that the Monticello meta data be preserved in FileTree > repositories. By preserving Monticello meta data, the packages can be > easily moved between FileTree and SmalltalkHub, etc. while faithfully > preserving the Monticello ancestry. Maintaining Monticello meta data is > critical for folks to be able to "dip their toe into the git pool" while > preserving Monticello ancestry. > > When I say "Cypress" (as opposed to FileTree), I think of a stripped down > implementation of FileTree where Monticello meta data is not stored on disk > and, perhaps more importantly the package loading code, in-image package > management and tool support is also stripped down to support a simple model > where package history and version numbers are non-existent. This particular > model is aimed at projects that spend their entire lives in "git" repos and > there is no desire, nor need to keep a parallel ancestry in the Monticello > meta data and I think that what you are asking for ... in fact with Cypress > package names do not need any package meta data ... the SHA of the commit > is all that is needed to uniquely identify packages [in tODE the > development environment is focused on the Metacello project and the package > is not really the focus, so right now the Metacello registry is capable of > tracking the SHA of the commit used to load a _project_, so I don't think > that a package needs to have any additional meta data like UUID or version > number or and the SHA of the commit at _project_ load time is all that is > needed] > > For Pharo, I think that GitFileTree provides you with support for a > metadata-less disk footprint, but the in-image support is still based on > Monticello --- at least that's what I understand about GitFileTree, since > up to now I haven't spent any time working with it ... that will change > this summer as I am working on a project in Pharo5. GitFileTree is an > extension of the "FileTree model" in that it is compatible with the current > in-image tools that all pretty much expect Monticello packages --- this > approach is needed because it is a big job to incorporate an alternate > source code management scheme in the in-image tools across the board ... If > one were to switch the pharo tool focus from the _package_ (Monticello > Browser) to the the _project_ (Project Browser) there would be additional > work to be done: 'save' of project means save all dirty packages in project > as well as a `git commit`, 'diff' of project means show changes for all > dirty packages in project, and there would be analogs for 'load', 'revert', > 'history' etc. > > For GemStone, I have written tODE to be git-aware from the beginning and I > have built tools to support Cypress package management as well[3] although > they _are_ 3 years old and would deserve additional work ... Internally we > are seriously considering adding Cypress support to the base image for the > GemStone 3.4 release and of course in the process of doing that work, I > assume that we'd make the code available for use in 3.2 and 3.3 as well. > > In the short term I think that a combination of Cypress package support > from Metacello, GitFileTree in Pharo and the updating of the Cypress tools > for tODE will allow you to share packages between Pharo and GemStone > without needing to create and maintain Monticello meta data ... in the > midterm Cypress support is slated for this year and if necessary I can make > changes to the current tODE FileTree implementation to allow the writing of > metadata-less packages -- I think GitFileTree records whether or not a > repository is metadata-less in a repository property file that I can use if > necessary ... > > Does this make sense? > > Dale > > [2] https://github.com/rjsargent/CypressReferenceImplementation > [3] > https://github.com/dalehenrich/tode/tree/master/repository/Topez-Server-Cyp… > >

July 10, 2016