Vm-dev May 2013

vm-dev@lists.squeakfoundation.org

20 participants
145 discussions

Re: Issue 44 in cog: Ephemerons integration
by cog＠googlecode.com 08 Aug '13

08 Aug '13

Comment #5 on issue 44 by siguc...(a)gmail.com: Ephemerons integration http://code.google.com/p/cog/issues/detail?id=44 Eliot proposed to change implementation to use separate object format for Ephemerons.

1 2

[Cog] primitiveLoadImageSegment fails
by Bert Freudenberg 20 Jul '13

20 Jul '13

That's primitive 99. With an updated Squeak trunk image I can load this project fine in the interpreter: http://etoys.squeak.org/svn/trunk/Etoys/Home.007.pr On Cog the primitive fails. Any idea what might be wrong? - Bert -

2 3

Issue 122 in cog: [BUG]: Frequent crashes when loading with MC
by cog＠googlecode.com 17 Jul '13

17 Jul '13

Status: Accepted Owner: sean.p.d...(a)gmail.com CC: esteba...(a)gmail.com, siguc...(a)gmail.com Labels: Type-Defect Priority-High New issue 122 by sean.p.d...(a)gmail.com: [BUG]: Frequent crashes when loading with MC http://code.google.com/p/cog/issues/detail?id=122 Still trying to come up with a simple way to reproduce. Pharo #20564 VM Virtual Machine --------------- /Applications/Pharo.app/Contents/MacOS/Pharo NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Feb 15 2013 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Feb 15 2013 git://gitorious.org/cogvm/blessed.git Commit: 05ed728452dc92732f9f23ce24a3c32bfdc0f4b8 Date: 2013-02-15 17:04:09 +0100 By: Igor Stasenko <siguctua(a)gmail.com> Jenkins build #14517 Mac Cocoa Cog 5.8b12 21-Sep-10 >1B0534FA-246C-47C5-AB29-7A76C81CCDCB< VMMaker versionString git://gitorious.org/cogvm/blessed.git Commit: 05ed728452dc92732f9f23ce24a3c32bfdc0f4b8 Date: 2013-02-15 17:04:09 +0100 By: Igor Stasenko <siguctua(a)gmail.com> Jenkins build #14517 NBCoInterpreter NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Feb 15 2013 NBCogit NativeBoost-CogPlugin-EstebanLorenzano.18 uuid: a53445f9-c0c0-4015-97a3-be7db8d9ed6b Feb 15 2013 *************************************************************************************************** *************************************************************************************************** *************************************************************************************************** Can't attach Mac crash report ("Issue attachment storage quota exceeded"): Process: Pharo [5079] Path: /Applications/Pharo.app/Contents/MacOS/Pharo Identifier: org.pharo-project.Pharo Version: Pharo VM 6.0-pre (21.0) Code Type: X86 (Native) Parent Process: launchd [230] Date/Time: 2013-02-22 20:00:12.830 -0500 OS Version: Mac OS X 10.8.2 (12C3012) Report Version: 10 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000002 VM Regions Near 0x2: --> __PAGEZERO 0000000000000000-0000000000001000 [ 4K] ---/--- SM=NUL /Applications/Pharo.app/Contents/MacOS/Pharo __TEXT 0000000000001000-0000000000244000 [ 2316K] r-x/rwx SM=COW /Applications/Pharo.app/Contents/MacOS/Pharo Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 org.pharo-project.Pharo 0x001aed8f mapPointersInObjectsFromto + 2767 Thread 1:: Dispatch queue: com.apple.libdispatch-manager 0 libsystem_kernel.dylib 0x93ab79ae kevent + 10 1 libdispatch.dylib 0x984a1c71 _dispatch_mgr_invoke + 993 2 libdispatch.dylib 0x984a17a9 _dispatch_mgr_thread + 53 Thread 2:: AQClient 0 libsystem_kernel.dylib 0x93ab47d2 mach_msg_trap + 10 1 libsystem_kernel.dylib 0x93ab3d78 mach_msg + 268 2 com.apple.CoreFoundation 0x9806b599 __CFRunLoopServiceMachPort + 185 3 com.apple.CoreFoundation 0x98070f7f __CFRunLoopRun + 1247 4 com.apple.CoreFoundation 0x9807063a CFRunLoopRunSpecific + 378 5 com.apple.CoreFoundation 0x980704ab CFRunLoopRunInMode + 123 6 com.apple.audio.toolbox.AudioToolbox 0x978fd0d9 GenericRunLoopThread::Entry(void*) + 209 7 com.apple.audio.toolbox.AudioToolbox 0x978fd004 CAPThread::Entry(CAPThread*) + 196 8 libsystem_c.dylib 0x96804557 _pthread_start + 344 9 libsystem_c.dylib 0x967eecee thread_start + 34 Thread 3: 0 libsystem_kernel.dylib 0x93ab6c72 __semwait_signal + 10 1 libsystem_c.dylib 0x9688ea61 nanosleep$UNIX2003 + 189 2 org.pharo-project.Pharo 0x001d8edc beatStateMachine + 236 3 libsystem_c.dylib 0x967eecee thread_start + 34 Thread 4: 0 libsystem_kernel.dylib 0x93ab70ee __workq_kernreturn + 10 1 libsystem_c.dylib 0x9680704c _pthread_workq_return + 45 2 libsystem_c.dylib 0x96806e19 _pthread_wqthread + 448 3 libsystem_c.dylib 0x967eecca start_wqthread + 30 Thread 5: 0 libsystem_kernel.dylib 0x93ab70ee __workq_kernreturn + 10 1 libsystem_c.dylib 0x9680704c _pthread_workq_return + 45 2 libsystem_c.dylib 0x96806e19 _pthread_wqthread + 448 3 libsystem_c.dylib 0x967eecca start_wqthread + 30 Thread 0 crashed with X86 Thread State (32-bit): eax: 0x00000002 ebx: 0x00000004 ecx: 0x219bd03c edx: 0x00000003 edi: 0x21843a58 esi: 0x00235918 ebp: 0x001ae2cc esp: 0xbffabd60 ss: 0x00000023 efl: 0x00010246 eip: 0x001aed8f cs: 0x0000001b ds: 0x00000023 es: 0x00000023 fs: 0x00000000 gs: 0x0000000f cr2: 0x00000002 Logical CPU: 2 External Modification Summary: Calls made by other processes targeting this process: task_for_pid: 5 thread_create: 0 thread_set_state: 0 Calls made by this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by all processes on this machine: task_for_pid: 2596 thread_create: 1 thread_set_state: 0 VM Region Summary: ReadOnly portion of Libraries: Total=157.2M resident=38.1M(24%) swapped_out_or_unallocated=119.0M(76%) Writable regions: Total=640.0M written=71.2M(11%) resident=77.0M(12%) swapped_out=12.2M(2%) unallocated=563.0M(88%) REGION TYPE VIRTUAL =========== ======= (null) (reserved) 384.0M reserved VM address space (unallocated) CG backing stores 11.1M CG image 80K CG raster data 96K CG shared images 224K CoreServices 9088K MALLOC 89.6M MALLOC guard page 48K Memory tag=240 4K Memory tag=242 12K Memory tag=243 4K Memory tag=35 4428K OpenCL 64K Stack 66.5M VM_ALLOCATE 144.1M __DATA 7568K __DATA/__OBJC 388K __IMAGE 528K __LINKEDIT 30.8M __OBJC 2180K __OBJC/__DATA 56K __PAGEZERO 4K __TEXT 126.3M __UNICODE 544K mapped file 101.0M shared memory 33.4M =========== ======= TOTAL 1.0G TOTAL, minus reserved VM space 627.6M Model: MacBookPro10,1, BootROM MBP101.00EE.B02, 4 processors, Intel Core i7, 2.6 GHz, 16 GB, SMC 2.3f32 Graphics: Intel HD Graphics 4000, Intel HD Graphics 4000, Built-In, 512 MB Graphics: NVIDIA GeForce GT 650M, NVIDIA GeForce GT 650M, PCIe, 1024 MB Memory Module: BANK 0/DIMM0, 8 GB, DDR3, 1600 MHz, 0x80AD, 0x484D5434314753364D465238432D50422020 Memory Module: BANK 1/DIMM0, 8 GB, DDR3, 1600 MHz, 0x80AD, 0x484D5434314753364D465238432D50422020 AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0xEF), Broadcom BCM43xx 1.0 (5.106.98.100.14) Bluetooth: Version 4.1.2f9 11046, 2 service, 11 devices, 1 incoming serial ports Network Service: Wi-Fi, AirPort, en0 Serial ATA Device: APPLE SSD SM768E, 751.28 GB USB Device: hub_device, 0x8087 (Intel Corporation), 0x0024, 0x1a100000 / 2 USB Device: FaceTime HD Camera (Built-in), apple_vendor_id, 0x8510, 0x1a110000 / 3 USB Device: hub_device, 0x8087 (Intel Corporation), 0x0024, 0x1d100000 / 2 USB Device: hub_device, 0x0424 (SMSC), 0x2512, 0x1d180000 / 3 USB Device: Apple Internal Keyboard / Trackpad, apple_vendor_id, 0x0262, 0x1d182000 / 5 USB Device: BRCM20702 Hub, 0x0a5c (Broadcom Corp.), 0x4500, 0x1d181000 / 4 USB Device: Bluetooth USB Host Controller, apple_vendor_id, 0x8286, 0x1d181300 / 6 -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 5

Issue 124 in cog: Segmentation fault while downloading or uploading packages
by cog＠googlecode.com 17 Jul '13

17 Jul '13

Status: Accepted Owner: esteba...(a)gmail.com Labels: Type-Defect Priority-Critical New issue 124 by esteba...(a)gmail.com: Segmentation fault while downloading or uploading packages http://code.google.com/p/cog/issues/detail?id=124 see https://code.google.com/p/pharo/issues/detail?id=7596 -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 2

Issue 123 in cog: vm crashes when dragging a window outside the world
by cog＠googlecode.com 17 Jul '13

17 Jul '13

Status: Accepted Owner: esteba...(a)gmail.com Labels: Type-Defect Priority-High New issue 123 by esteba...(a)gmail.com: vm crashes when dragging a window outside the world http://code.google.com/p/cog/issues/detail?id=123 move the window outside (in top), and see the crash :) this happens in mac, with USE_CORE_GRAPHICS -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 2

Re: [Pharo-fuel] [Pharo-dev] Corrupt BlockClosure
by Max Leske 10 Jun '13

10 Jun '13

I can now reprocuce corrupt sessions. The trick is to debug DFSession>>numberOfMethodCalls: 1. start new session 2. debug "DFSession uniqueInstance printString" 3. step into #numberOfMehthodCalls 4. proceed 5. stop the session 5. right click on the new session in the session browser and click "Export session" 6. boom! The reason is of course, that now the compiled method of #numberOfMethodCalls is referenced by the session and will be serialized by Fuel and when Fuel gets to the corrupt BlockClosure, serialization fails. So the real question still is: how did that BlockClosure obtain a wrong start PC? What I find particularly interesting, is that even changing the method does not fix the BlockClosure. I added the line "Transcript show: 'foo'." before the block (so the block should get a new start PC). Then running the procedure detailed above still produced an open debugger. To illustrate that the block did indeed not get fixed I ran "BlockClosure allInstances select: [ :e | e startpc = 59 ]", with 59 being the new startPC ("55 <8F 01 00 03> closureNumCopied: 0 numArgs: 1 bytes 59 to 61"). The result does not include the block. Any ideas? Max On 24.05.2013, at 08:10, roberto.minelli(a)usi.ch wrote: > Hi, > > Thanks all of you for interest ;) > > On May 24, 2013, at 7:15 AM, Max Leske <maxleske(a)gmail.com> > wrote: > >> I played around with reverting the method and serializing but that doesn't change anything (the existing BlockClosure is obviously not modified). >> Then I thought that maybe the method was changed during a running DFSession but still couldn't reproduce. > > Me neither!! > >> >> @Roberto >> Can you tell us anything about what you did befor / during / after running your session? > > Nope. Unfortunately I've a couple of "broken sessions" I cannot serialize because of that bug.. But all of them refers sooner or later to the DFSession>>#numberOfMethodCalls method. Dunno why. > >> @Roberto >> Is it possible to reproduce the stack with a new session? Or did this only happen once? > > I have no clue how to reproduce, but it did not happen only once. As I said, there are 3/4 sessions I couldn't export due to this SubscriptOutOfBounds. > > Cheers, > Roby > > >> >> >> On 24.05.2013, at 06:44, Max Leske <maxleske(a)gmail.com> wrote: >> >>> >>> On 23.05.2013, at 22:58, Camille Teruel <camille.teruel(a)gmail.com> wrote: >>> >>>> Hi, >>>> >>>> This is indeed strange, the BlockClosure has an incorrect startpc (31 instead of 43). You can fix it with: >>>> theBlock instVar: 2 put: 43. >>>> The wrong startpc corresponds to the beginning of the block in the previous version of the method (DFSession>>#numberOfMethodCalls), but I don't know why. >>> >>> Would it help to recompile the method? >>> >>>> I don't know fuel enough but could it be because the method of the block changed between serialization and materialization? >>> >>> No, there was never a materialization of that session. >>> >>>> >>>> Camille >>>> >>>> On 23 mai 2013, at 21:02, Max Leske wrote: >>>> >>>>> Hi Marcus >>>>> >>>>> Roberto sent this mail to the Fuel-dev list. When we looked at the problem we noticed that serialization fails because of a corrupt BlockClosure. Since that's not really our territorry Mariano suggested to forward this to you. >>>>> >>>>> The image with the corrupt BlockClosure is available here: https://dl.dropboxusercontent.com/u/6281855/DFlow-SubscriptOutOfBounds.zip. >>>>> To see the stack, right click on the only entry in the right window and click "export session". You'll find the corrupt BlockClosure at BlockClosure>>fuelAccept: >>>>> >>>>> @Roberto >>>>> Is it possible to reproduce the stack with a new session? Or did this only happen once? >>>>> >>>>> >>>>> Cheers, >>>>> Max >>>>> >>>>> >>>>> Begin forwarded message: >>>>> >>>>>> From: Mariano Martinez Peck <marianopeck(a)gmail.com> >>>>>> Subject: Re: [Pharo-fuel] [Fuel] SubscriptOutOfBounds: 27 >>>>>> Date: 23. Mai 2013 14:23:45 MESZ >>>>>> To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> >>>>>> Reply-To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> >>>>>> >>>>>> Indeed, it would be nice if you can known which CompiledMethod and blockclosure are having the problem. Not only the source code but the real bytecodes. >>>>>> Also, can you isolate and just try to serialize them alone and reproduce the problem? In other words, a reproducible test case? :) >>>>>> Thanks! >>>>>> >>>>>> >>>>>> On Thu, May 23, 2013 at 8:41 AM, Max Leske <maxleske(a)gmail.com> wrote: >>>>>> What's the compiled method? Is it a special one? Which selector in which class? >>>>>> >>>>>> Max >>>>>> >>>>>> On 23.05.2013, at 12:45, "roberto.minelli(a)usi.ch" <roberto.minelli(a)usi.ch> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> While using Fuel in a 2.0 image to serialize some objects (including CompiledMethods) I'm getting this error: SubscriptOutOfBounds: 27. >>>>>>> >>>>>>> I spent hours in the debugger before writing this email, but I'm not able to figure out why this is happening. I attach the full stack of the error (STACK#1). >>>>>>> >>>>>>> I understood that it has something to do with a particular CompiledMethod in my image and/or a BlockClosure which for some reason cannot be printed (i.e., the printString returns <error in printString: evaluate "self printString" to debug>) and when I try to printString to debug I got the STACK#2 which in turn does not bring me to any possible solution. >>>>>>> >>>>>>> Hope some of you will have an intuition on that or at least tell me where to look or how to script a possible workaround. >>>>>>> >>>>>>> Thanks in advance, >>>>>>> Roby >>>>>>> >>>>>>> ############################################################################################ >>>>>>> ######################################### STACK#1 ########################################### >>>>>>> ########################################################################################### >>>>>>> CompiledMethod(Object)>>errorSubscriptBounds: >>>>>>> CompiledMethod(Object)>>at: >>>>>>> InstructionStream>>interpretNextInstructionFor: >>>>>>> CompiledMethod>>abstractBytecodeMessageAt: in Block: [(InstructionStream new method: self pc: pc)... >>>>>>> BlockClosure>>on:do: >>>>>>> CompiledMethod>>abstractBytecodeMessageAt: >>>>>>> BlockClosure>>blockCreationBytecodeMessage >>>>>>> BlockClosure>>endPC >>>>>>> BlockClosure>>abstractBytecodeMessagesDo: >>>>>>> BlockClosure>>isClean >>>>>>> BlockClosure>>shouldBeSubstitutedByCleanCopy >>>>>>> BlockClosure>>fuelAccept: >>>>>>> FLFullGeneralMapper(FLLightGeneralMapper)>>mapAndTrace: >>>>>>> FLFullGlobalMapper>>mapAndTrace: in Block: [(anObject class == CompiledMethod... >>>>>>> FLLargeIdentityDictionary>>at:ifAbsent: >>>>>>> FLFullGlobalMapper>>mapAndTrace: >>>>>>> FLPluggableSubstitutionMapper>>mapAndTrace: >>>>>>> FLPluggableSubstitutionMapper>>mapAndTrace: >>>>>>> FLAnalysis>>mapAndTrace: >>>>>>> FLAnalysis>>run >>>>>>> FLAnalyzer>>setDefaultAnalysis in Block: [:anObject | (FLAnalysis... >>>>>>> FLAnalyzer>>analysisFor: >>>>>>> FLSerialization>>analysisStep >>>>>>> FLSerialization>>run >>>>>>> DFSerializer(FLSerializer)>>setDefaultSerialization in Block: [:anObject :anEncoder | (FLSerialization... >>>>>>> DFSerializer(FLSerializer)>>serialize:on: in Block: [:anEncoder | ... >>>>>>> FLEncoder class>>on:globalEnvironment:do: in Block: [aBlock value: anEncoder] >>>>>>> BlockClosure>>ensure: >>>>>>> FLEncoder class>>on:globalEnvironment:do: >>>>>>> DFSerializer(FLSerializer)>>serialize:on: >>>>>>> >>>>>>> >>>>>>> ############################################################################################ >>>>>>> ######################################### STACK#2 ########################################### >>>>>>> ############################################################################################ >>>>>>> Decompiler(Object)>>error: >>>>>>> Decompiler>>decompileBlock: >>>>>>> BlockClosure>>decompile >>>>>>> BlockClosure>>printOn: >>>>>>> BlockClosure(Object)>>printStringLimitedTo: in Block: [:s | self printOn: s] >>>>>>> String class(SequenceableCollection class)>>streamContents:limitedTo: >>>>>>> BlockClosure(Object)>>printStringLimitedTo: >>>>>>> BlockClosure(Object)>>printString >>>>>>> BlockClosure>>DoIt >>>>>>> Compiler>>evaluate:in:to:notifying:ifFail:logged: >>>>>>> SmalltalkEditor>>evaluateSelectionAndDo: in Block: [rcvr class evaluatorClass new... >>>>>>> BlockClosure>>on:do: >>>>>>> SmalltalkEditor>>evaluateSelectionAndDo: >>>>>>> SmalltalkEditor>>evaluateSelection >>>>>>> PluggableTextMorph>>doIt in Block: [textMorph editor evaluateSelection] >>>>>>> PluggableTextMorph>>handleEdit: in Block: [result := editBlock value] >>>>>>> TextMorphForEditView(TextMorph)>>handleEdit: >>>>>>> PluggableTextMorph>>handleEdit: >>>>>>> PluggableTextMorph>>doIt >>>>>>> SmalltalkEditor class>>buildSmalltalkEditorKeymappingsOn: in Block: [:morph | morph doIt] >>>>>>> BlockClosure>>cull: >>>>>>> BlockClosure>>cull:cull: >>>>>>> BlockClosure>>cull:cull:cull: >>>>>>> KMCategoryTarget>>completeMatch:buffer: >>>>>>> KMKeymap>>notifyCompleteMatchTo:buffer: in Block: [:l | l completeMatch: self buffer: aBuffer] >>>>>>> Array(SequenceableCollection)>>do: >>>>>>> KMKeymap>>notifyCompleteMatchTo:buffer: >>>>>>> KMKeymap>>onMatchWith:notify:andDo: >>>>>>> KMCategory>>onMatchWith:notify:andDo: in Block: [:entry | entry... >>>>>>> Set>>do: >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-fuel mailing list >>>>>>> Pharo-fuel(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-fuel mailing list >>>>>> Pharo-fuel(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Mariano >>>>>> http://marianopeck.wordpress.com >>>>>> _______________________________________________ >>>>>> Pharo-fuel mailing list >>>>>> Pharo-fuel(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >>>>> >>>> >>> >> >> _______________________________________________ >> Pharo-fuel mailing list >> Pharo-fuel(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel > > > _______________________________________________ > Pharo-fuel mailing list > Pharo-fuel(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel

2 8

Fwd: Squeak source code licence declaration for ARM fast bitblt
by tim Rowledge 31 May '13

31 May '13

This should make all licence aficionados happy - Begin forwarded message: > From: "Ben Avison" <bavison(a)riscosopen.org> > Subject: Squeak source code licence declaration > Date: 30 May, 2013 10:43:11 AM PDT > To: "tim Rowledge" <tim(a)rowledge.org> > Cc: "Eben Upton" <eben(a)raspberrypi.org>, "Steve Revill" <srevill(a)riscosopen.org> > > Tim, > > I hereby confirm that all the source code I have contributed to the Squeak > VM is my own work and is licensed under the MIT Licence, and I am happy for > the VM to use it under those terms. > > One uncommon tool is required to build the source code: asasm. This is > licensed under GPL version 2. To build it from source, you can do the > following: > > sudo apt-get install bison flex libarchive-dev > svn co svn://svn.riscos.info/gccsdk/trunk/tools/asasm > # at this point, edit src/output.c to insert #define ELF_EABI > autoreconf --install > ./configure --target=arm-linux-gnueabihf > make > DESTDIR=/usr/local/bin sudo make install > > It might be worth us getting this set up as a package for Raspbian, and > maybe upstream it even further to ARM Debians in general? At the moment, the > CMake makefiles I've written assume asasm is available if you're targeting > ARM. > > Ben > tim -- tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim To succeed in politics, it is often necessary to rise above your principles.

2 1

Adding CPU specific code for fast bitblt on ARM
by tim Rowledge 31 May '13

31 May '13

In order to make the Raspberry Pi Squeak faster we've built a fairly large chunk of ARM specific code to implement a good fraction of the bitlbt plugin. It *ought* to speed up some common blits by around 5-10X once all functioning fully. My current problem is integrating it nicely so it doesn't get in the way of 'normal' code. I have fudged the BitBltSimulation code a little to make the relevant connections with, I hope, minimal intrusion and maintained the compile-time configuration that should support Jenkins builds etc. A single -DARM_FAST_BLT in CFLAGS triggers #including a header and taking a branch in copyBits to the specialised code. It's not the most elegant code in the world but the best I could come up with without rewriting everything. That all works to generate suitable code for the Pi and seems not to mangle anything for other platforms. I'll make sure it works for RISC OS sometime soon, too. The other issue is where to store the rest of the hand-written code. Right now it's mostly in platforms/Cross/plugins/BitBltPlugin which doesn't really seem right. It's cross platform in the sense of RISC OS & any ARM linux but hardly universally cross-platform. Would it annoy anyone if it stays there? Would naming it BitBltPluginARM make it nicer? There are a couple of other files that *are* platform specific and implement cpu discovery to configure the tricks used in the rest of the code. One is currently in unix/src/vm/intplugins/BitBltPlugin, which certainly isn't suitable. There's also a config.cmake fragment currently in unix/plugins/BitBltPlugin which clearly would need some work to handle non-ARM builds. Oh, the other, other issue is integrating it into the make world for both plain interp and stack/cog. Right now I have the ST code integrated into the cog vmmaker but not the plain vmmaker, but the makefile stuff is for the CMake used in the plain interp branch. Sigh. I'll move the code across to the plain vmmaker today and that ought to result in something that would build clean on an ARM unix but likely not non-ARM. Changing the cog makefiles to incorporate the new code…. yuck. autoconf. Help. tim -- tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim Useful random insult:- Put a lens in each ear and you've got a telescope.

4 14

FT2Plugin for Freetype: Freetype-Plugin-IgorStasenko.64.mcz
by squeak-dev-noreply＠lists.squeakfoundation.org 30 May '13

30 May '13

Igor Stasenko uploaded a new version of Freetype-Plugin to project FT2Plugin for Freetype: http://www.squeaksource.com/FreetypePlugin/Freetype-Plugin-IgorStasenko.64.… ==================== Summary ==================== Name: Freetype-Plugin-IgorStasenko.64 Author: IgorStasenko Time: 30 May 2013, 4:10:21 am UUID: 958b30c7-6b34-4c72-ab55-507c60b6d188 Ancestors: Freetype-Plugin-dtl.63 - fix bug in #primitiveLoadOutlineSizesFrom:

1 0

Fwd: Bug#710375: squeak-vm: uses removed pcre_info
by Bert Freudenberg 30 May '13

30 May '13

Begin forwarded message: > Resent-From: Julian Taylor <jtaylor.debian(a)googlemail.com> > From: Julian Taylor <jtaylor.debian(a)googlemail.com> > Subject: Bug#710375: squeak-vm: uses removed pcre_info > Date: 30. Mai 2013 12:48:58 MESZ > Resent-To: debian-bugs-dist(a)lists.debian.org > To: Debian Bug Tracking System <submit(a)bugs.debian.org> > Resent-Cc: Debian Squeak Team <pkg-squeak-devel(a)lists.alioth.debian.org> > Reply-To: Julian Taylor <jtaylor.debian(a)googlemail.com>, 710375(a)bugs.debian.org > > Package: squeak-vm > Version: 1:4.10.2.2614-1 > Severity: important > > > squeak-vm uses the system pcre library which does not provide the > prce_info anymore: > int pcre_fullinfo(const pcre *code, const pcre_extra *extra, > int what, void *where); > > The pcre_fullinfo() function returns information about a > compiled pat- > tern. It replaces the pcre_info() function, which was removed > from the > library at version 8.30, after more than 10 years of obsolescence. > > it is used in: > unix/src/vm/intplugins/RePlugin/RePlugin.c:354 > interpreterProxy->pushInteger(pcre_info((pcre *)pcrePtr, NULL, NULL)); > > > note this causes a build failure in ubuntu: > https://launchpadlibrarian.net/141082673/buildlog_ubuntu-saucy-amd64.squeak… > - Bert -

1 0

← Newer
1
2
3
4
5
6
7
...
15
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev May 2013