Re: [Pharo-users] Best method for connecting to an Oracle 11g database
Hi Arron Did you try Garage from https://github.com/pharo-rdbms Stef On Fri, Apr 20, 2018 at 7:22 AM, Aaron Blakeman wrote: > Hello, > > I'm trying to use Pharo 6 to connect to an Oracle 11g database. I tried > using dbxtalk with the opendbx driver, but I can't seem to get that to load > cleanly into a Pharo 6 image. > > Before I spend alot of time trying to debug DBXtalk I wanted to see if > anyone else had any recommendations. Is there currently any better method > for connecting from Pharo 6 to an Oracle database? > > Thanks!
[Pharo-users] Best method for connecting to an Oracle 11g database
Hello, I'm trying to use Pharo 6 to connect to an Oracle 11g database. I tried using dbxtalk with the opendbx driver, but I can't seem to get that to load cleanly into a Pharo 6 image. Before I spend alot of time trying to debug DBXtalk I wanted to see if anyone else had any recommendations. Is there currently any better method for connecting from Pharo 6 to an Oracle database? Thanks!
Re: [Pharo-users] Where do we go now ?
Hi, On this matter, when I named my project, "Grafoscopio" I thought in something evocative and unique, because of the Spanish words "grafo" (graph) and grafía[1][2] (graphy, related with writing like in "ortografía" "orthography". After naming it I discover there was a old device related with writing and visualization, also called Grafoscopio[3][4], but I got good search rankings because of the uniqueness of the word[5][6]. Being my first project and lacking any programming style, the "Smalltalk with Style" book didn't make any sense at that time, but now, with more experience, I wonder, from time to time, how I could/should (re)name the software and its classes. [1] http://www.wordreference.com/definicion/graf%c3%ada [2] http://www.wordreference.com/es/en/translation.asp?spen=graf%C3%ADa [3] https://www.museodelprado.es/actualidad/multimedia/el-grafoscopio/722c13b2-8f3c-42a0-a1ab-1374bbca9d5f [4] https://www.museodelprado.es/en/whats-on/exhibition/the-graphoscope/81bfb972-aade-4c24-93b2-dbd7e26e5e4a [5] https://duckduckgo.com/?q=grafoscopio&t=ffsb&atb=v76-7&ia=web [6] https://www.google.com/search?hl=en&q=grafoscopio Cheers, Offray On 13/04/18 09:01, Esteban A. Maringolo wrote: > On 13/04/2018 10:41, p...@highoctane.be wrote: >> A somewhat unique name makes it easier to google for it (like Roassal >> Pharo, or DeepTraverser Pharo, or Zinc Pharo). >> These will give us hits that are relevant. >> >> Try System Browser, Inspector... >> >> And Apple has worked with NSObject and stuff like that without too much >> trouble (at a much larger scale for whatever XyzKit they released). >> Ah, yes, they used the "Kit" suffix. Maybe can we have something like >> that with Pharo. Like SystemBrowserKit ( nah, too Appleish. > > But I prefer these names: > * Calypso System Browser > * Calypso Debugger > * Iceberg Source Control Management > * Zinc HTTP Client > * Zinc HTTP Server > * Fuel Serialization > * Glamorous Spotter [*] > * etc. > > [*] I particularly dislike "Glamorous" adjective. > > In the case of wrapper for libraries I'm hesitant to decide whether to > indicate pharo name in it or not. > I mean stuff like a NaCl wrapper calling it "NaCl-Pharo" instead of > calling "Salty". > > >> Let's try SystemBrowserMeccano (longish), or SystemBrowserPack (too >> bland), or SystemBrowserGear (why not), SystemBrowserRig (this one >> sounds cool actually)). > Fortunately in the past the lack of namespaces caused the use of > prefixes instead of suffixes. > > With time prefixes become invisible. > > A suffix, instead, will get into all your names, bothering with other > existing suffixes like `Component`, `Model`, `Collection`, and so on. > > > > > > >
Re: [Pharo-users] Creating a repository with Iceberg
Perfect.. works for me.. Thanks! On April 19, 2018 at 2:42:08 PM, Bernardo Ezequiel Contreras (vonbecm...@gmail.com) wrote: World>>System>>Settings>>Tools>>Software Configuration Management>>Iceberg and choose the File format type: tonel/filetree peace, sergio photographer, journalist, visionary Public Key: http://bit.ly/29z9fG0 #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV http://www.codeandmusic.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101 signature.asc Description: Message signed with OpenPGP using AMPGpg
Re: [Pharo-users] Creating a repository with Iceberg
you can avoid it if you go to World>>System>>Settings>>Tools>>Software Configuration Management>>Iceberg and choose the File format type: tonel/filetree On Thu, Apr 19, 2018 at 3:33 PM, Bernardo Ezequiel Contreras < vonbecm...@gmail.com> wrote: > see > https://github.com/pharo-vcs/iceberg/issues/579 > > > > On Thu, Apr 19, 2018 at 1:04 PM, sergio ruiz wrote: > >> I am just getting started with Iceberg. >> >> In creating a new repo on my local machine, I keep getting this error: >> >> Object>>doesNotUnderstand: #asSymbol >> >> it has a beef with this line: >> >> defaultFileFormat >> ^ Smalltalk at: self defaultFileFormatType asSymbol >> >> Do i need to set this in my image? >> >> Thanks! >> >> >> >> >> peace, >> sergio >> photographer, journalist, visionary >> >> Public Key: http://bit.ly/29z9fG0 >> #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV >> http://www.codeandmusic.com >> http://www.twitter.com/sergio_101 >> http://www.facebook.com/sergio101 >> > > > > -- > Bernardo E.C. > > Sent from a cheap desktop computer in South America. > -- Bernardo E.C. Sent from a cheap desktop computer in South America.
Re: [Pharo-users] Creating a repository with Iceberg
see https://github.com/pharo-vcs/iceberg/issues/579 On Thu, Apr 19, 2018 at 1:04 PM, sergio ruiz wrote: > I am just getting started with Iceberg. > > In creating a new repo on my local machine, I keep getting this error: > > Object>>doesNotUnderstand: #asSymbol > > it has a beef with this line: > > defaultFileFormat > ^ Smalltalk at: self defaultFileFormatType asSymbol > > Do i need to set this in my image? > > Thanks! > > > > > peace, > sergio > photographer, journalist, visionary > > Public Key: http://bit.ly/29z9fG0 > #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV > http://www.codeandmusic.com > http://www.twitter.com/sergio_101 > http://www.facebook.com/sergio101 > -- Bernardo E.C. Sent from a cheap desktop computer in South America.
[Pharo-users] Creating a repository with Iceberg
I am just getting started with Iceberg. In creating a new repo on my local machine, I keep getting this error: Object>>doesNotUnderstand: #asSymbol it has a beef with this line: defaultFileFormat ^ Smalltalk at: self defaultFileFormatType asSymbol Do i need to set this in my image? Thanks! peace, sergio photographer, journalist, visionary Public Key: http://bit.ly/29z9fG0 #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV http://www.codeandmusic.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101 signature.asc Description: Message signed with OpenPGP using AMPGpg
Re: [Pharo-users] [ANN] Pharo Sprint Apr 20
This is tomorrow. > On 13 Apr 2018, at 14:32, Marcus Denker wrote: > > Pharo Sprint Apr 20 > > https://association.pharo.org/event-2789579 > > We will organize a Pharo sprint / Moose dojo Apr 20 , starting at > 10:00am. (Local Time Paris). > > Goals of this sprint: > > • Pharo 7 issues > > Remote Sprint > Remotely, you can join us on Discord. During the sprint, we synchronize > local and remote Pharo sprinters: > > > Known Local Sprint meetings > > Lille/France: > It will be at the Inria Lille, Building B, third floor (RMoD offices). > As the building is not open to the public, please contact us before if you > plan to come > >
Re: [Pharo-users] [Pharo-Launcher] call for tests on Windows
The good news is that the same version of Pharo Launcher worked essentially perfectly under Windows 10. As expected, the launcher was installed in AppData\Local. However, I continue to find an AppData\Roaming\pharo directory created when the launcher was installed. Its contents are as I described in the issue created for the Windows 7 installation. Suggestion: Some of the lists are quite long. It might be useful to be able to sort them by e.g. name or date of last change, both ascending and descending. On Mon, Apr 16, 2018 at 9:54 AM, Richard Sargent < richard.sarg...@gemtalksystems.com> wrote: > I ran the launcher against my Windows 7 office computer and have created > an issue with my feedback. > https://github.com/pharo-project/pharo-launcher/issues/93 > > > > On Mon, Apr 16, 2018 at 7:13 AM, Christophe Demarey < > christophe.dema...@inria.fr> wrote: > >> Hi, >> >> Regarding the various problems Pharo Launchers had on Windows, we worked >> on a new installer based on Advanced Installer [1] to avoid UAC (User >> Account Control) and write permissions problems. This new installer now >> installs Pharo Launcher in the user’s local app data folder (where for >> sure, he has write permissions). Pharo Launcher also now have its own icon >> and use its own name instead of Pharo. Also, the uninstaller now works as >> expected. Last but not least, the installer is now signed to avoid warning >> of Windows Defender. >> Thanks to Ben Coman who did the first version of the packaging using >> Advanced Installer (was NSIS). >> This version should also improve the launch of Pharo images on Windows. >> >> So, please could you install and test this new version: and report any >> problem with it? http://files.pharo.org/pharo-launcher/win-alpha/ >> We do not have windows users around so it’s hard to know if it works >> outside our tests boxes. >> >> Thanks, >> Christophe >> >> [1] https://www.advancedinstaller.com/ >> > >
Re: [Pharo-users] SDL2SpecialCharacterMapping problem
Thank you very much 2018-04-19 3:34 GMT-03:00 Esteban Lorenzano : > Hi again, > > well, the problem is that 64bit images are translated from a 32bit version > and some particular dictionaries need to be rehashed. > > 1073741904 is a long integer in 32bit and a small integer in 64bit ;) > > If you execute this: > > SDL2Structure allSubclassesDo: #compileFields. > OSWindowMorphicEventHandler initialize. > SDL2SpecialCharacterMapping initialize. > > and you will be ok :) > > Of course, right fix would be to rehash dictionaries when converting. > and right-right fix would be to bootstrap also 64bit version instead > bootstrap 32bit and then translate. > > but since just a few people uses SDL2 right now, the problem arose > recently (in fact, I realised it recently, when I was doing some > experiments). > > cheers! > Esteban > > > On 19 Apr 2018, at 00:41, alvaro piorno wrote: > > Ok, > waiting for your answer. > Thnks. > > 2018-04-18 16:10 GMT-03:00 Esteban Lorenzano : > >> In fact, I have the answer. >> But I’m afk, I will answer later, sorry :) >> >> On 18 Apr 2018, at 21:00, alvaro piorno >> wrote: >> >> Hi Ben, >> The thing is that i found that the problem can be reproduced without my >> code. >> >> >> >> The class has a class variable named "Mappings" (photo shows an inspector >> of it). >> There are associations for left and right arrow: >> - (1073741904 -> arrowLeft) >> - (1073741903 -> arrowRight) >> If i send "Mappings at: 1073741904" i get "arrowLeft", >> but if i send "Mappings at: 1073741903" i get "nil" instead of >> "arrowRight". >> >> This is done automatically when handling OS events, but as this fails i >> am not getting associated character for "arrowRight". >> >> Just in case i send you the information you requested. >> Thanks >> >> * OS/VM/Image versions:* >> >> Operating System/Hardware >> - >> unix linux-gnu x86_64 >> >> Virtual Machine >> --- >> /home/alvaro/Desktop/pharo6.1-64/bin/lib/pharo/5.0-201707201942/pharo >> CoInterpreter VMMaker.oscog-eem.2254 uuid: >> 4f2c2cce-f4a2-469a-93f1-97ed941df0ad >> Jul 20 2017 >> StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: >> 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 >> VM: 201707201942 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >> Date: Thu Jul 20 12:42:21 2017 -0700 $ Plugins: 201707201942 >> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ >> >> Unix built on Jul 20 2017 20:40:36 Compiler: 4.6.3 >> VMMaker versionString VM: 201707201942 https://github.com/OpenSmallta >> lk/opensmalltalk-vm.git $ Date: Thu Jul 20 12:42:21 2017 -0700 $ >> Plugins: 201707201942 https://github.com/OpenSmallta >> lk/opensmalltalk-vm.git $ >> CoInterpreter VMMaker.oscog-eem.2254 uuid: >> 4f2c2cce-f4a2-469a-93f1-97ed941df0ad >> Jul 20 2017 >> StackToRegisterMappingCogit VMMaker.oscog-eem.2252 uuid: >> 2f3e9b0e-ecd3-4adf-b092-cce2e2587a5c Jul 20 2017 >> >> Image >> >> 6.1 >> >> 2018-04-01 19:59 GMT-03:00 Ben Coman : >> >>> Hi Alvaro, >>> >>> This is not an area I've been involved in, but just a general comment... >>> >>> Can you export a self contained example from your code that can be loaded >>> into a fresh Image that demonstrate the problem? >>> Its always easier if people can see the problem with their own eyes. >>> >>> Also, what version OS/VM/Image are you running? >>> i.e. World Menu > System > System Reporter >>> >>> cheers -ben >>> >>> On 1 April 2018 at 11:45, alvaro piorno >>> wrote: >>> Hi, Iam having a problem handling some OSKeywordEvents. These events should have character associated. The mapping is resolved by SDL2SpecialCharacterMapping using a dictionary(Mappings), it has the mapping, for example, for left arrow and right arrow. It resolve correctly for "left arrow" with key: 1073741904(Integer) , but it does not found "right arrow" with key: 1073741903(Integer). Both keys are present. Any idea? >>> >> > >
Re: [Pharo-users] C struct in 32 bits vs 64 bits VM
A C long is guaranteed to be at least 32 bits in size. long long is guaranteed to be 64 bits. int depends on the platform. Phil On Thu, Apr 19, 2018 at 10:30 AM, Andres Valloud < avall...@smalltalk.comcastbiz.net> wrote: > The relevant spec does not state 'long' is of any particular size. > > On 4/19/18 1:24 , Serge Stinckwich wrote: > >> >> >> On Thu, Apr 19, 2018 at 9:13 AM, Serge Stinckwich >> mailto:serge.stinckw...@gmail.com>> wrote: >> >> I try to understand differences between 32 bits and 64 bits FFI >> support for C structures. >> >> I build a class called MyStruct subclass of FFIExternalStructure. >> and define a layout for this structure like this one : >> >> MyStruct class>>fieldsDesc >> "self rebuildFieldAccessors" >> >> ^ #( >> int index ;) >> >> and then I generate automatically the field accessors. >> >> If I use a 32 bit VM, the following method is generated to access >> the index field : >> >> index >> "This method was automatically generated" >> ^handle signedLongAt: OFFSET_INDEX >> >> and if I use a 64 bits VM, the same method is generated ... >> >> I'm a bit puzzled because, if sizeof(int) = sizeof(long) in a 32 >> bits VM, they have different for 64 bits VM (sizeof(int) = 4 and >> sizeof(long) = 8). >> >> Someone to explain me or this is a bug ? >> >> >> Ok I have understood ... >> >> signedLongAt: method does not return a long as the name seems to >> indicate but in fact a 32 bits integer. >> So it works in both 32 and 64 bits VM. >> >> Maybe signedInt32At: would have been a better name :-) >> >> >> -- >> Serge Stinckwich >> UMI UMMISCO 209 (SU/IRD/UY1) >> "Programs must be written for people to read, and only incidentally for >> machines to execute." >> >> http://www.doesnotunderstand.org/ >> > > >
Re: [Pharo-users] C struct in 32 bits vs 64 bits VM
On Thu, Apr 19, 2018 at 10:32 AM, Thierry Goubier wrote: > > > 2018-04-19 10:24 GMT+02:00 Serge Stinckwich : > >> >> >> On Thu, Apr 19, 2018 at 9:13 AM, Serge Stinckwich < >> serge.stinckw...@gmail.com> wrote: >> >>> I try to understand differences between 32 bits and 64 bits FFI support >>> for C structures. >>> >>> I build a class called MyStruct subclass of FFIExternalStructure. >>> and define a layout for this structure like this one : >>> >>> MyStruct class>>fieldsDesc >>> "self rebuildFieldAccessors" >>> >>> ^ #( >>> int index ;) >>> >>> and then I generate automatically the field accessors. >>> >>> If I use a 32 bit VM, the following method is generated to access the >>> index field : >>> >>> index >>> "This method was automatically generated" >>> ^handle signedLongAt: OFFSET_INDEX >>> >>> and if I use a 64 bits VM, the same method is generated ... >>> >>> I'm a bit puzzled because, if sizeof(int) = sizeof(long) in a 32 bits >>> VM, they have different for 64 bits VM (sizeof(int) = 4 and sizeof(long) = >>> 8). >>> >>> Someone to explain me or this is a bug ? >>> >>> >> Ok I have understood ... >> >> signedLongAt: method does not return a long as the name seems to indicate >> but in fact a 32 bits integer. >> So it works in both 32 and 64 bits VM. >> >> Maybe signedInt32At: would have been a better name :-) >> > > Maybe this is because long in C does not guarantee 64bits, only long long > does. > > Thierry > > > >> >> >> -- >> Serge Stinckwich >> UMI UMMISCO 209 (SU/IRD/UY1) >> "Programs must be written for people to read, and only incidentally for >> machines to execute."http://www.doesnotunderstand.org/ >> > >
Re: [Pharo-users] C struct in 32 bits vs 64 bits VM
On Thu, Apr 19, 2018 at 9:30 AM, Andres Valloud < avall...@smalltalk.comcastbiz.net> wrote: > The relevant spec does not state 'long' is of any particular size. > > yes I know this is why we have also a platformLongAt: method. I was just wondering, why we have a signedLongAt: method that return always a 32 bits int. Would be better to have be more explicit: platformIntAt: platformLongAt: int32At: int64At: and same for unsigned versions. -- Serge Stinckwich UMI UMMISCO 209 (SU/IRD/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."http://www.doesnotunderstand.org/
Re: [Pharo-users] C struct in 32 bits vs 64 bits VM
signed long is now specified as: Capable of containing at least the [−2,147,483,647, +2,147,483,647] range; so at least 32 bits; and signed long long Capable of containing at least the [−9,223,372,036,854,775,807, +9,223,372,036,854,775,807] range [C99] so at least 64 bits; and long long size >= long size So a 32 bits long is legal, as well as a 64bits long, and as well as a 256bits long :) 2018-04-19 10:30 GMT+02:00 Andres Valloud : > The relevant spec does not state 'long' is of any particular size. > > On 4/19/18 1:24 , Serge Stinckwich wrote: >> >> >> >> On Thu, Apr 19, 2018 at 9:13 AM, Serge Stinckwich >> mailto:serge.stinckw...@gmail.com>> wrote: >> >> I try to understand differences between 32 bits and 64 bits FFI >> support for C structures. >> >> I build a class called MyStruct subclass of FFIExternalStructure. >> and define a layout for this structure like this one : >> >> MyStruct class>>fieldsDesc >> "self rebuildFieldAccessors" >> >> ^ #( >> int index ;) >> >> and then I generate automatically the field accessors. >> >> If I use a 32 bit VM, the following method is generated to access >> the index field : >> >> index >> "This method was automatically generated" >> ^handle signedLongAt: OFFSET_INDEX >> >> and if I use a 64 bits VM, the same method is generated ... >> >> I'm a bit puzzled because, if sizeof(int) = sizeof(long) in a 32 >> bits VM, they have different for 64 bits VM (sizeof(int) = 4 and >> sizeof(long) = 8). >> >> Someone to explain me or this is a bug ? >> >> >> Ok I have understood ... >> >> signedLongAt: method does not return a long as the name seems to >> indicate but in fact a 32 bits integer. >> So it works in both 32 and 64 bits VM. >> >> Maybe signedInt32At: would have been a better name :-) >> >> >> -- >> Serge Stinckwich >> UMI UMMISCO 209 (SU/IRD/UY1) >> "Programs must be written for people to read, and only incidentally for >> machines to execute." >> >> http://www.doesnotunderstand.org/ > >
Re: [Pharo-users] C struct in 32 bits vs 64 bits VM
2018-04-19 10:24 GMT+02:00 Serge Stinckwich : > > > On Thu, Apr 19, 2018 at 9:13 AM, Serge Stinckwich < > serge.stinckw...@gmail.com> wrote: > >> I try to understand differences between 32 bits and 64 bits FFI support >> for C structures. >> >> I build a class called MyStruct subclass of FFIExternalStructure. >> and define a layout for this structure like this one : >> >> MyStruct class>>fieldsDesc >> "self rebuildFieldAccessors" >> >> ^ #( >> int index ;) >> >> and then I generate automatically the field accessors. >> >> If I use a 32 bit VM, the following method is generated to access the >> index field : >> >> index >> "This method was automatically generated" >> ^handle signedLongAt: OFFSET_INDEX >> >> and if I use a 64 bits VM, the same method is generated ... >> >> I'm a bit puzzled because, if sizeof(int) = sizeof(long) in a 32 bits VM, >> they have different for 64 bits VM (sizeof(int) = 4 and sizeof(long) = 8). >> >> Someone to explain me or this is a bug ? >> >> > Ok I have understood ... > > signedLongAt: method does not return a long as the name seems to indicate > but in fact a 32 bits integer. > So it works in both 32 and 64 bits VM. > > Maybe signedInt32At: would have been a better name :-) > Maybe this is because long in C does not guarantee 64bits, only long long does. Thierry > > > -- > Serge Stinckwich > UMI UMMISCO 209 (SU/IRD/UY1) > "Programs must be written for people to read, and only incidentally for > machines to execute."http://www.doesnotunderstand.org/ >
Re: [Pharo-users] C struct in 32 bits vs 64 bits VM
The relevant spec does not state 'long' is of any particular size. On 4/19/18 1:24 , Serge Stinckwich wrote: On Thu, Apr 19, 2018 at 9:13 AM, Serge Stinckwich mailto:serge.stinckw...@gmail.com>> wrote: I try to understand differences between 32 bits and 64 bits FFI support for C structures. I build a class called MyStruct subclass of FFIExternalStructure. and define a layout for this structure like this one : MyStruct class>>fieldsDesc "self rebuildFieldAccessors" ^ #( int index ;) and then I generate automatically the field accessors. If I use a 32 bit VM, the following method is generated to access the index field : index "This method was automatically generated" ^handle signedLongAt: OFFSET_INDEX and if I use a 64 bits VM, the same method is generated ... I'm a bit puzzled because, if sizeof(int) = sizeof(long) in a 32 bits VM, they have different for 64 bits VM (sizeof(int) = 4 and sizeof(long) = 8). Someone to explain me or this is a bug ? Ok I have understood ... signedLongAt: method does not return a long as the name seems to indicate but in fact a 32 bits integer. So it works in both 32 and 64 bits VM. Maybe signedInt32At: would have been a better name :-) -- Serge Stinckwich UMI UMMISCO 209 (SU/IRD/UY1) "Programs must be written for people to read, and only incidentally for machines to execute." http://www.doesnotunderstand.org/
Re: [Pharo-users] C struct in 32 bits vs 64 bits VM
On Thu, Apr 19, 2018 at 9:13 AM, Serge Stinckwich < serge.stinckw...@gmail.com> wrote: > I try to understand differences between 32 bits and 64 bits FFI support > for C structures. > > I build a class called MyStruct subclass of FFIExternalStructure. > and define a layout for this structure like this one : > > MyStruct class>>fieldsDesc > "self rebuildFieldAccessors" > > ^ #( > int index ;) > > and then I generate automatically the field accessors. > > If I use a 32 bit VM, the following method is generated to access the > index field : > > index > "This method was automatically generated" > ^handle signedLongAt: OFFSET_INDEX > > and if I use a 64 bits VM, the same method is generated ... > > I'm a bit puzzled because, if sizeof(int) = sizeof(long) in a 32 bits VM, > they have different for 64 bits VM (sizeof(int) = 4 and sizeof(long) = 8). > > Someone to explain me or this is a bug ? > > Ok I have understood ... signedLongAt: method does not return a long as the name seems to indicate but in fact a 32 bits integer. So it works in both 32 and 64 bits VM. Maybe signedInt32At: would have been a better name :-) -- Serge Stinckwich UMI UMMISCO 209 (SU/IRD/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."http://www.doesnotunderstand.org/
[Pharo-users] C struct in 32 bits vs 64 bits VM
I try to understand differences between 32 bits and 64 bits FFI support for C structures. I build a class called MyStruct subclass of FFIExternalStructure. and define a layout for this structure like this one : MyStruct class>>fieldsDesc "self rebuildFieldAccessors" ^ #( int index ;) and then I generate automatically the field accessors. If I use a 32 bit VM, the following method is generated to access the index field : index "This method was automatically generated" ^handle signedLongAt: OFFSET_INDEX and if I use a 64 bits VM, the same method is generated ... I'm a bit puzzled because, if sizeof(int) = sizeof(long) in a 32 bits VM, they have different for 64 bits VM (sizeof(int) = 4 and sizeof(long) = 8). Someone to explain me or this is a bug ? Thank you. -- Serge Stinckwich UMI UMMISCO 209 (SU/IRD/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."http://www.doesnotunderstand.org/
