- Pharo-users - lists.pharo.org

Re: [Pharo-users] Creating a repository with Iceberg

by Bernardo Ezequiel Contreras

see https://github.com/pharo-vcs/iceberg/issues/579 On Thu, Apr 19, 2018 at 1:04 PM, sergio ruiz <sergio.rrd(a)gmail.com> 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.

April 19, 2018

Creating a repository with Iceberg

by sergio ruiz

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

April 19, 2018

Re: [Pharo-users] [ANN] Pharo Sprint Apr 20

by Marcus Denker

This is tomorrow. > On 13 Apr 2018, at 14:32, Marcus Denker <marcus.denker(a)inria.fr> 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 > >

April 19, 2018

Re: [Pharo-users] [Pharo-Launcher] call for tests on Windows

by Richard Sargent

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.sargent(a)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.demarey(a)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/ >> > >

April 19, 2018

Re: [Pharo-users] SDL2SpecialCharacterMapping problem

by alvaro piorno

Thank you very much 2018-04-19 3:34 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > 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 <alvaropiorno100(a)gmail.com> wrote: > > Ok, > waiting for your answer. > Thnks. > > 2018-04-18 16:10 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> In fact, I have the answer. >> But Iâm afk, I will answer later, sorry :) >> >> On 18 Apr 2018, at 21:00, alvaro piorno <alvaropiorno100(a)gmail.com> >> wrote: >> >> Hi Ben, >> The thing is that i found that the problem can be reproduced without my >> code. >> >> <asd.png> >> â >> 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 <btc(a)openinworld.com>: >> >>> 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 <alvaropiorno100(a)gmail.com> >>> 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? >>>> >>>> >>> >> > >

April 19, 2018

Re: [Pharo-users] C struct in 32 bits vs 64 bits VM

by phil＠highoctane.be

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 < avalloud(a)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 >> <serge.stinckwich(a)gmail.com <mailto:serge.stinckwich@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/ >> > > >

April 19, 2018

Re: [Pharo-users] C struct in 32 bits vs 64 bits VM

by phil＠highoctane.be

On Thu, Apr 19, 2018 at 10:32 AM, Thierry Goubier <thierry.goubier(a)gmail.com > wrote: > > > 2018-04-19 10:24 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>: > >> >> >> On Thu, Apr 19, 2018 at 9:13 AM, Serge Stinckwich < >> serge.stinckwich(a)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/ >> > >

April 19, 2018

Re: [Pharo-users] C struct in 32 bits vs 64 bits VM

by Thierry Goubier

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 <avalloud(a)smalltalk.comcastbiz.net>: > 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 >> <serge.stinckwich(a)gmail.com <mailto:serge.stinckwich@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/ > >

April 19, 2018

Re: [Pharo-users] C struct in 32 bits vs 64 bits VM

by Serge Stinckwich

On Thu, Apr 19, 2018 at 9:30 AM, Andres Valloud < avalloud(a)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/

April 19, 2018

Re: [Pharo-users] C struct in 32 bits vs 64 bits VM

by Thierry Goubier

2018-04-19 10:24 GMT+02:00 Serge Stinckwich <serge.stinckwich(a)gmail.com>: > > > On Thu, Apr 19, 2018 at 9:13 AM, Serge Stinckwich < > serge.stinckwich(a)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/ >

April 19, 2018