September 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] looking for boring morphs
by Esteban Lorenzano Sept. 24, 2011

Sept. 24, 2011

Hi, I have a customer who are asking me for a very small app... but a desktop app, not the usual web app I'm more used to do... and of course, I'm doing it with pharo! So far... this is working really well... much easier as I supposed it would be :) I'm using glamour, magritte, keybindings, hpdf, mongodb... and small tweaks by my self to make it work as expected, but not so much. (btw... I want to say that a couple of years ago, this wont be an option at all... this is due to the great effort the pharo community is doing, and I'm really proud of it. Thank you guys!) well... now... I need some morphs a regular management application usually needs: 1) NumberInputFieldMorph (A child of TextMorph or PluggableTextMorph who allows different kind of numbers -> this is easy to do, but better if it is already somewhere) 2) DateInputFieldMorph (a morph with a "date picker" -> this is harder, because I have very limited knowledge about morphic) 3) I'm sure there are others I didn't needed yet, but there are needed in this kind of applications so... does someone has this kind of morphs somewhere? I would really appreciate it, because you know... it is doable, but time is tyrant and better if I can reuse someones work ;) cheers, Esteban

5 5

[Pharo-project] [1.4] pre-build 14163
by Marcus Denker Sept. 24, 2011

Sept. 24, 2011

... with jenkins dead here is a current updated image of 1.4: I will link it on http://www.pharo-project.org/pharo-download/unstable-1-4 https://gforge.inria.fr/frs/download.php/29095/Pharo-1.4-14163.zip -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] image persistency does not seem to work
by Tudor Girba Sept. 24, 2011

Sept. 24, 2011

Hi, I am testing the latest Pier2 based on Pharo 1.3, and I got an error when trying to use the image-based persistency. The error happens in: PRImagePersistency>>saveImageAndBackupAs: aString ... image openSourceFiles; saveImageSegments; snapshot: true andQuit: false in particular, the SmalltalkImage does not understand saveImageSegments anymore. Is this some cleanup that happened in Pharo and that requires a new package to be loaded? Cheers, Doru -- www.tudorgirba.com "To utilize feedback, you first have to acquire it."

2 2

Re: [Pharo-project] image persistency does not seem to work
by Marcus Denker Sept. 24, 2011

Sept. 24, 2011

On Sep 24, 2011, at 6:50 PM, Tudor Girba wrote: > Hi, > > I am testing the latest Pier2 based on Pharo 1.3, and I got an error when trying to use the image-based persistency. > > The error happens in: > > PRImagePersistency>>saveImageAndBackupAs: aString > ... > image openSourceFiles; saveImageSegments; snapshot: true andQuit: false > > in particular, the SmalltalkImage does not understand saveImageSegments anymore. Is this some cleanup that happened in Pharo and that requires a new package to be loaded? > We started to clean up ImageSegments in 1.3. Most of ImageSegments is there (and even cleaned and fixed by Mariano while he analyzed the code). We removed all of ImageSegment code in the image in 1.4, though. After *very* careful analysis *and* implementing a better replacement... (Fuel). The #saveImageSegments when saving the Image itself I removed in 1.3 already (after sending a mail to the list to ask if anyone uses it). The idea was that on image save, if image segments are written to disk, it would copy them over if you rename the image on save: saveImageSegments: previousFullImageName "This method is used for example when you save an image with another name. In this case, if there are segments written to files and there are ImageSegment instances, then it copies the file from the previous image location, to the new one. It is like a backup of the segment files when renaming an image. " | haveSegs oldImageSegDir theClass newImageSegDir | "If the class does not exist or has no instances, it has no sense to backUp the segments." self areThereImageSegments ifFalse: [ ^ self ]. theClass := Smalltalk globals at: #ImageSegment. oldImageSegDir := theClass segmentDirectoryFrom: previousFullImageName. newImageSegDir := theClass segmentDirectory. "create the folder" oldImageSegDir fileNames do: [ :theName | | imageSegmentName "copy all segment files" | imageSegmentName := oldImageSegDir pathName , FileDirectory slash , theName. newImageSegDir copyFileWithoutOverwriteConfirmationNamed: imageSegmentName toFileNamed: theName ] So if your image has no image segments, than it's ok to just remove the call. Marcus -- Marcus Denker -- http://marcusdenker.de

1 0

Re: [Pharo-project] jenkis is down
by Marcus Denker Sept. 23, 2011

Sept. 23, 2011

Yes, known problem and reported since yesterday... On Sep 23, 2011, at 7:31 PM, Mariano Martinez Peck wrote: > > > -- > Mariano > http://marianopeck.wordpress.com > -- Marcus Denker -- http://marcusdenker.de

2 1

Re: [Pharo-project] Pharo web page download button
by Marcus Denker Sept. 23, 2011

Sept. 23, 2011

On Sep 23, 2011, at 9:47 PM, Noury Bouraqadi wrote: > Hi, > > Probably this was already discussed, but I just want to send a reminder. > > The download button at the top should point to 1.3. Yes, but Adrian is on Holidays in India and I can't change it (at least I have not found out how). I think I wil pester the hotline of Cmsbox (even though we are technically not a customer ;-) Marcus -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] Pharo Sprint November 2011 - Noviembre 2011 @ Smalltalks 2011
by Guillermo Polito Sept. 23, 2011

Sept. 23, 2011

Hi! I'm gathering the attendants the Pharo Sprint the day before the Smalltalks2011 in Universidad Nacional de Quilmes, so we can guess the space and other requirements needed. If you are attending, please fill the form below :). Estoy juntando a la gente que quiera participar del Pharo Sprint el dÃa previo a la Smalltalks, en la Universidad Nacional de Quilmes. Si queres participar, completÃ¡ el formulario de abajo. Gracias, Thanks! Guille Si tienes problemas para visualizar o enviar este formulario, puedes rellenarlo online: https://spreadsheets.google.com/spreadsheet/viewform?formkey=dHlKdUdvYnF3c3… Pharo Sprint November 2011 - Noviembre 2011 I will attend to the Pharo Sprint on november 2 of 2011, from 2pm to 8pm, at Universidad Nacional de Quilmes, the day previous to the conference. AsistirÃ© al Pharo Sprint del miÃ©rcoles 2 de noviembre de 2011, desde las 14:00 a las 20:00, en la UNQui, dÃa previo a la conferencia. First and Last Name - Nombre y Apellido * Email * Con la tecnologÃa de Google Docs <http://docs.google.com> Informar sobre abusos<https://spreadsheets.google.com/spreadsheet/reportabuse?formkey=dHlKdUdvYnF…>- Condiciones del servicio <http://www.google.com/accounts/TOS> - Otros tÃ©rminos<http://www.google.com/google-d-s/terms.html>

1 0

[Pharo-project] Pharo web page download button
by Noury Bouraqadi Sept. 23, 2011

Sept. 23, 2011

Hi, Probably this was already discussed, but I just want to send a reminder. The download button at the top should point to 1.3. Thanks for all Pharo contributors, Noury -- http://twitter.com/#!/NouryBouraqadi

1 0

Re: [Pharo-project] Pharo for iOS
by Marcus Denker Sept. 23, 2011

Sept. 23, 2011

On Sep 23, 2011, at 8:56 PM, Alexandre Bergel wrote: > Actually, you have to install DrGeo. > http://dl.dropbox.com/u/9643745/DrGeo/DrGeoTestBF.html > > You can then use whatever image you wish instead, by just dragging and dropping it from your desktop to iTunes. > *but* isn't that binary compiled to run only on certain ipads? Like yours and a handful of others? Marcus -- Marcus Denker -- http://marcusdenker.de

2 1

[Pharo-project] new Cog VMs available [please read]
by Eliot Miranda Sept. 23, 2011

Sept. 23, 2011

...in http://www.mirandabanda.org/files/Cog/VM/VM.r2493/. These VMs are not much changed from the 2487 VMs, BUT the 2487 VMs introduced a bug while providing faster doesNotUnderstand: processing. These 2493 VMs contain code to help identify that bug. If you're already using a 2487 VM or newer /please/ upgrade to these 2493 VMs asap. I want to see C stack backtraces from these VMs whenever they crash. Typically the VMs produce a crash.dmp file somewhere in the file system (may be / on Mac OS, may be in the directory containing the VM or the current directory on other OSs, but it will be called crash.dmp, and on Mac OS info will be printed to the console or to a crash report window). The C backtrace part of things looks like this on windows: Stack backtrace: [004193EA] ??? + 4297706 in CogCode [00442337] ??? + 4465463 in CogCode [00442685] ??? + 4466309 in CogCode [00583018] ??? + 5779480 in CogCode [0040124B] ??? + 4198987 in CogCode [00401298] ??? + 4199064 in CogCode [7C816FE7] RegisterWaitForInputIdle + 73 in kernel32.dll [7C913BA7] RtlDosApplyFileIsolationRedirection_Ustr + 1824 in ntdll.dll this on Mac C stack backtrace: 0 nsvm 0x00038689 reportStackState + 105 1 nsvm 0x0003893e sigsegv + 110 2 libsystem_c.dylib 0x9b2e259b _sigtramp + 43 3 ??? 0xffffffff 0x0 + 4294967295 4 nsvm 0x0008b2a5 sufficientSpaceAfterGC + 69 5 nsvm 0x0008d11d primitiveNewWithArg + 221 6 ??? 0x068b9899 0x0 + 109811865 7 nsvm 0x00098d10 initStackPagesAndInterpret + 512 8 nsvm 0x0002c530 EventLoopEventHandler + 16 Etc. So please feel free to email me the crash.dmp's and/or the C backtraces of any crashes you have with 2493 VMs. Hopefully I'll track down this regression quickly. For the curious, what's the bug? I don't know yet. The symptom is that very rarely the inline cache linking machinery for MNU PICs relinks the call of an MNU PIC to the address 0x00000013, which causes a crash when the call is next executed, long after the bug bit. These VMs contain code that will raise an error when the relinking attempt is made, which should reveal the bug. Here's the 2493 readme: CogVM binaries as per VMMaker.oscog-eem.125/r2493. Add callsite link/relocate checks to catch the call 0x00000013 MNU callsite relinking bug. Reduce the size of the simStack to something proportional to LargeContextSize. In the Newspeak VM, don't cd to the image's directory on win32. Fix off-by-one error in Win32OSProcessPlugin>primitiveGetCurrentWorkingDirectory so it doesn't include an erroneous trailing null. Fix the 1Gb allocation bug. -- best, Eliot

1 1