- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Two fixes for review

by Ben Coman

April 3, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30810 Home: https://github.com/pharo-project/pharo-core

April 3, 2014

[pharo-project/pharo-core] 1e1e45: 30810

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 1e1e45faf48b5245176cde218225385cc2e8d76b https://github.com/pharo-project/pharo-core/commit/1e1e45faf48b5245176cde21… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-04-03 (Thu, 03 Apr 2014) Changed paths: A Athens-Cairo.package/CairoGlyph.class/class/as yet unclassified/byteAlignment.st A NativeBoost-Core.package/NBExternalArray.class/class/session management/initializeForNewSession.st A NativeBoost-Core.package/NBExternalArray.class/class/session management/updateElementSize.st A NativeBoost-Core.package/NBExternalStructure.class/class/session management/initializeForNewSession.st A NativeBoost-Core.package/NBExternalStructure.class/class/session management/updateFieldOffsets.st A NativeBoost-Core.package/NBExternalStructureFields.class/instance/computing/updateFieldOffsetsFor_.st A NativeBoost-Core.package/NBExternalTypeValue.class/class/session management/initializeForNewSession.st A NativeBoost-Core.package/NBExternalTypeValue.class/class/session management/updateValueSize.st A NativeBoost-Core.package/NBExternalUnionFields.class/instance/accessing/updateFieldOffsetsFor_.st A NativeBoost-Core.package/NativeBoost.class/instance/bootstrapping/initializeForNewSession.st M NativeBoost-Core.package/NativeBoost.class/instance/initialization/initialize.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script463.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30810.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 30810 13150 Different memory alignment on different platforms https://pharo.fogbugz.com/f/cases/13150 http://files.pharo.org/image/30/30810.zip

April 3, 2014

strange creation time

by Tudor Girba

Hi, I just stumbled across a strange piece of code, and I am wondering about the reasons behind it: FileSystemStore>>creationTime: aPath self nodeAt: aPath ifPresent: [ :entry | ^ self basicCreationTime: entry ] ifAbsent: [ ^ false ]. In what case does returning "false" make sense? Doru -- www.tudorgirba.com "Every thing has its own flow"

April 3, 2014

Re: [Pharo-dev] Thanks to all of you who asked

by phil＠highoctane.be

Crossed my mind: create some visualizations using Roassal about the quake(s) in Chile and advertise your local biz presence. #datajournalism, This can turn big. Le 3 avr. 2014 10:22, "Sean P. DeNigris" <sean(a)clipperadams.com> a Ã©crit : > Tudor Girba-2 wrote > > I just read the news. > > > > I am happy you are fine! > > +1 to both. And thank you for letting us know you are okay! > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Thanks-to-all-of-you-who-asked-tp4752334p4752465.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

April 3, 2014

Re: [Pharo-dev] [Moose-dev] Re: Re: Re: Fwd: Font problem is still there

by J.F. Rick

Cool. I just loaded the latest NB and Athens (as Igor sent around) but my image is not fully up to date. I'll try downloading a new one and reloading my work from packages. I just wanted to make sure that this was worth the effort. If that doesn't work, then I'll send Igor my image. Cheers, Jeff On Wed, Apr 2, 2014 at 10:55 PM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > > On 02 Apr 2014, at 14:46, J.F. Rick <self(a)je77.com> wrote: > > Is this supposed to fix the font rendering problem or some other font > problem? I tried it and it doesn't seem to help the rendering problem. > > > normally it should fix the font PrObLem > can you check that you loaded the latest NB? > > > Cheers, > > Jeff > > > On Tue, Apr 1, 2014 at 6:27 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> okay i uploaded updated configs for NativeBoost and Athens into official >> repositories for these projects. >> >> Gofer new smalltalkhubUser: 'Pharo' project: 'NativeBoost'; >> configuration; >> load. >> >> ConfigurationOfNativeBoost loadDevelopment. >> >> >> >> Gofer new smalltalkhubUser: 'Pharo' project: 'Athens'; >> configuration; >> load. >> >> ConfigurationOfAthens loadDevelopment. >> >> >> shall do the trick.. >> >> for more details see >> >> https://pharo.fogbugz.com/f/cases/13150/Different-memory-alignment-on-diffe… >> >> >> >> On 28 March 2014 21:13, Pharo4Stef <pharo4Stef(a)free.fr> wrote: >> >>> thanks Igor. >>> I'm trying to look at the font reloading bug. >>> >>> >>> On 28 Mar 2014, at 17:19, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> >>> https://pharo.fogbugz.com/f/cases/13150/Different-memory-alignment-on-diffe… >>> >>> >>> On 28 March 2014 16:42, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>>> so, the quick and dirty fix is to put: >>>> >>>> CairoGlyph class>>byteAlignment >>>> >>>> NativeBoost platformId = NativeBoostConstants win32PlatformId >>>> ifTrue: [ ^ 8 ]. >>>> ^ super byteAlignment >>>> >>>> and then: >>>> >>>> CairoGlyph rebuildFieldAccessors >>>> CairoGlyphsArray initialize >>>> >>>> (note you must run this snippet each time your image changes platform).. >>>> >>>> and i need more time to fix it for real, because it is NB issue, to >>>> automatically recalculate the structs size >>>> if it changes platform.. (which also means you cannot store instances >>>> of struct in image which survive the session) >>>> ... damn.. that's going to be complicated. >>>> >>>> --- >>>> >>>> >>>> >>>> On 28 March 2014 16:27, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> >>>>> >>>>> >>>>> >>>>> On 28 March 2014 16:01, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>> >>>>>> >>>>>> Ookkayy.. >>>>>> so, current status: >>>>>> >>>>>> - finally we got an agreement that big red square because of font >>>>>> loading issues and font rendering artifacts is two separate issues. >>>>>> Thanks! >>>>>> - i am not going to address font-loading issue here and now.. >>>>>> (because we spent time on it earlier today with Stef already and you should >>>>>> have the report on it in separate mail). >>>>>> >>>>>> - we seem to be agreed that it is best to use same (up-to-date >>>>>> version) of software when reporting issues to work on them. Thanks again. :) >>>>>> >>>>>> - while on linux and mac things seem to be working fine, i can >>>>>> confirm that there is rendering artifacts (same as reported by Vincent) on >>>>>> Windows. >>>>>> >>>>>> so i going to explore what causing this problem.. >>>>>> >>>>>> ... and found the cause: >>>>> >>>>> On windows, for unknown reason, the structure (cairo_glyph_t) uses >>>>> different memory space alignment than on mac and linux >>>>> >>>>> fieldsDesc >>>>> ^ #( >>>>> ulong index; >>>>> double x; >>>>> double y; >>>>> ) >>>>> >>>>> on mac and linux , the size of this structure in memory = 4 + 8 + 8 = >>>>> 20 bytes, >>>>> on windows, however, due to 8-byte alignment, it is 4 + 8 + 8 + (4 >>>>> alignment) bytes... >>>>> >>>>> this causing the effect that if you copy array of glyphs in memory, >>>>> it does not copying whole array by slightly less (because it uses >>>>> wrong struct size which is smaller than it is).. >>>>> and because of that, you got weird artefacts at the tail of string, >>>>> replaced by misplaced/invalid characters etc.. >>>>> because it is basically read from uninitialized part of memory with >>>>> random data. >>>>> >>>>> i going to fix structure alignment for windows from default 4 bytes to >>>>> 8 bytes.. >>>>> but this is not very good news.. because this affecting many things... >>>>> (as you can imagine, not only cairo/athens working with external >>>>> structures, which need to be properly aligned). >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko. >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > Jochen "Jeff" Rick, Ph.D. > http://www.je77.com/ > Skype ID: jochenrick > > > -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

April 3, 2014

Re: [Pharo-dev] Thanks to all of you who asked

by Sean P. DeNigris

Tudor Girba-2 wrote > I just read the news. > > I am happy you are fine! +1 to both. And thank you for letting us know you are okay! ----- Cheers, Sean -- View this message in context: http://forum.world.st/Thanks-to-all-of-you-who-asked-tp4752334p4752465.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 3, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] af5386: 30809

by Sean P. DeNigris

GitHub wrote > 13143 Integrate Versionner 2.7 > ... > Which include these:... Great job! Thanks, Christophe (and Marcus for integrating so quickly) :) ----- Cheers, Sean -- View this message in context: http://forum.world.st/pharo-project-pharo-core-af5386-30809-tp4752340p47524… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 3, 2014

bug on windows ioShowDisplay for bitdepth 16/8/4 (big endian)

by Nicolai Hess

There is still something wrong with byte/word swap in windows ioShowDisplay code attached are two screenshots squeak 4.5 image with cogvm from http://files.pharo.org/vm/cogmt/win/ pharo 30793 image with latest vm from http://files.pharo.org/vm/pharo/win/ showing this bug after setting the Display depth to 16 (Display newDepth:16) sqwin32window.c has three variants for doing the byte_swap/word_swap on bitdepths with big endian to convert to lsb This one is active and causes this error. # if __GNUC__ >= 3 # define BYTE_SWAP(w) __asm__("bswap %0" : "=r" (w) : "r" (w)) # define WORD_SWAP(w) __asm__("roll $16, %0" : "=r" (w) : "r" (w)) This one would work # else # define BYTE_SWAP(w) __asm__("bswap %%eax" : "=eax" (w) : "eax" (w)) # define WORD_SWAP(w) __asm__("roll $16, %%eax" : "=eax" (w) : "eax" (w)) This one, of course, works too # else # define BYTE_SWAP(w) w = (w << 24) | ((w & 0xFF00) << 8) | ((w >> 8) & 0xFF00) | (w >> 24) # define WORD_SWAP(w) w = (( (unsigned)(w) << 16) | ((unsigned) (w) >> 16)) This one is not there but would work (at least with gcc > 4.5 # define BYTE_SWAP_MY(w) __asm__("bswap %0" : "+r" (w)) # define WORD_SWAP_MY(w) __asm__("roll $16, %0" : "+r" (w)) But actually I don't know assembler and/or the gcc inline code syntax, so I don't know what is wrong with the first version :) Nicolai btw, you can not test this bug with the current squeak 4.5 all in on image, as it uses a rather old vm. Third screenshot: using the latest stable pharo-vm, it looks much more wrong, as there was another(?) bug that is fixed already(?) - i don't know :)

April 3, 2014

Re: [Pharo-dev] <quote author="Sean P. DeNigris"> I think the tree nodes should be based on name-matching and not only per-package. For example: </quote> In 4.0, let's query the Metacello configurations to find out exactly what packages belong to which project and categorize from there, but until then, I think this is already an improvement:

by Sean P. DeNigris

Igor Stasenko wrote > cool Yes, very! ----- Cheers, Sean -- View this message in context: http://forum.world.st/Re-Nautilus-Package-Tree-tp4738896p4752462.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 3, 2014