June 2019 - Pharo-dev - lists.pharo.org

Ring renaming in P8, Manifests and deprecations

by Torsten Bergmann

Hi, just to let you know: If one develops a project in Pharo 7 (or before) including a manifest with banned rules this may lead to trouble in upcoming Pharo 8. Within the manifest you will find methods referencing "RGPackage" class: "code-critics" ruleRBLiteralArrayContainsCommaRuleV1FalsePositive ^ #(#(#(#RGPackage #(#'Funny-App')) #'2019-06-02T17:05:15.359384+02:00') ) If you load the code into latest Pharo 8 it is not possible to browse the manifest class in Calypso without errors as RGPackage class is missing in Pharo 8. This goes back to a PR from Pavel: https://github.com/pharo-project/pharo/pull/3226 to consolidate and rename RGPackage into RGPackageDefinition. I support the PR - but not the way how it is done as it does not consider keeping and deprecating the old RGPackage class. For sure one can easily adopt the Manifest methods by replacing #RGPackage with #RGPackageDefinition - but be aware that accidentially or not we add more and more burden especially to new users and future migrators. IMHO we should "deprecate" and keep classes around at least one pharo version iteration whenever possible. (see also the deprecation guide http://forum.world.st/Deprecation-guide-for-methods-classes-and-packages-td…) We could have RGPackageDefinition as the new class, and keep the old class RGPackage as a subclass of RGPackageDefinition in a "Deprecated80" package so we can easily remove it with the start of the P9 iteration. I also wonder why we still have the "Deprecated70" package around in latest P8 image and why we do not remove it as usual and just start a fresh "Deprecated80" package. It was a simple scheme and worked in the past without much hazzle. Last time this was asked there was a discussions about a possible migration tool - but so far without any visible progress to my knowledge. Even if such a tool exists it could use the "Deprecated70" package even after removal by just loading it... Thanks T.

June 3, 2019

Re: [Pharo-dev] [Vm-dev] Image crashing on startup, apparently during GC

by Andrei Chis

Hi, I seem to be getting more of these errors recently. I'm on Mac Mojave 10.14.5, Pharo-7.0.3 64 bit, with the current stable vm (Mac OS X built on Jan 5 2019 19:11:02 ). Running the leak checker returns some leaks: (lldb) run --leakcheck 31 broken.image Process 3327 launched: '/Users/andrei/Documents/Pharo/images/pharo-vm/PharoAssert.app/Contents/MacOS/Pharo' (x86_64) leak in free chunk 0x17221e8b8 @ 0 = 0x17521e888 is unmapped leak in free chunk 0x17421e890 @ 0 = 0x17a21e830 is unmapped leak in free chunk 0x17521e888 @ 0 = 0x18021e7d8 is unmapped leak in free chunk 0x17a21e830 @ 0 = 0x187d3e278 is unmapped Process 3327 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 frame #0: 0x0000000100001230 Pharo`warning Pharo`warning: -> 0x100001230 <+0>: pushq %rbp 0x100001231 <+1>: movq %rsp, %rbp 0x100001234 <+4>: pushq %rbx 0x100001235 <+5>: pushq %rax Target 0: (Pharo) stopped. The when using `storePointerUncheckedofObjectwithValue` I seem to get an error: (lldb) call storePointerUncheckedofObjectwithValue(0,0x17221e8b8,nilObj) error: warning: got name from symbols: nilObj error: 'storePointerUncheckedofObjectwithValue' has unknown return type; cast the call to its declared return type Is this a problem with the way I compiled the assert vm? And is there a way to explore how the leaked objects get created? Cheers, Andrei On Fri, Mar 23, 2018 at 11:02 PM Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > Hi Damien, > > On Fri, Mar 23, 2018 at 1:52 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> Hi Damien, >> >> On Fri, Mar 23, 2018 at 12:38 PM, Damien Pollet <damien.pollet(a)gmail.com> wrote: >>> >>> >>> Here are the files (image and various outputs). Running with --leakcheck does mention a few object leaks (see output.txt); >> >> >> Indeed the image is corrupt at start-up. See below. >> >>> >>> I'm not sure where to get or how to build an assert VM. >> >> >> When you build a phar. VM under build.macos64x64/pharo.cog.spur using the mvm script (mvm -A) you produce an assert VM in PharoAssert.app. > > > Note that if you build an Assert VM you will be able to manually patch the image in lldb so that you can rescue it. It looks like this: > > $ lldb PharoAssert.app/Contents/MacOS/Pharo > > (lldb) target create "/Users/eliot/oscogvm/build.macos64x64/pharo.cog.spur/PharoAssert.app/Contents/MacOS/Pharo" > Current executable set to '/Users/eliot/oscogvm/build.macos64x64/pharo.cog.spur/PharoAssert.app/Contents/MacOS/Pharo' (x86_64). > (lldb) settings set -- target.run-args "clap_broken.d9e5daa.image" > (lldb) b warning > Breakpoint 1: 3 locations. > (lldb) run --leakcheck 31 clap_broken.d9e5daa.image > Process 31569 launched: '/Users/eliot/oscogvm/build.macos64x64/pharo.cog.spur/PharoAssert.app/Contents/MacOS/Pharo' (x86_64) > object leak in 0x10f919658 @ 0 = 0x122216538 > object leak in 0x10fbb3448 @ 0 = 0x122216760 > object leak in 0x10fbb3480 @ 0 = 0x1222166a8 > object leak in 0x10ff384f0 @ 0 = 0x122d480b0 > object leak in 0x10ff38518 @ 0 = 0x122d480b0 > object leak in 0x10ff385d0 @ 0 = 0x122d480b0 > Process 31569 stopped > * thread #1: tid = 0x5b6d56, 0x0000000100001a83 Pharo`warning(s="checkHeapIntegrityclassIndicesShouldBeValid(0, 1) 57196") + 19 at gcc3x-cointerp.c:44, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1 > frame #0: 0x0000000100001a83 Pharo`warning(s="checkHeapIntegrityclassIndicesShouldBeValid(0, 1) 57196") + 19 at gcc3x-cointerp.c:44 > 41 sqInt warnpid, erroronwarn; > 42 void > 43 warning(char *s) { /* Print an error message but don't necessarily exit. */ > -> 44 if (erroronwarn) error(s); > 45 if (warnpid) > 46 printf("\n%s pid %ld\n", s, (long)warnpid); > 47 else > (lldb) call storePointerUncheckedofObjectwithValue(0,0x10f919658,nilObj) > (sqInt) $0 = 4478138592 > (lldb) call storePointerUncheckedofObjectwithValue(0,0x10fbb3448,nilObj) > (sqInt) $1 = 4478138592 > (lldb) call storePointerUncheckedofObjectwithValue(0,0x10fbb3480,nilObj) > (sqInt) $2 = 4478138592 > (lldb) call storePointerUncheckedofObjectwithValue(0,0x10ff384f0,nilObj) > (sqInt) $3 = 4478138592 > (lldb) call storePointerUncheckedofObjectwithValue(0,0x10ff38518,nilObj) > (sqInt) $4 = 4478138592 > (lldb) call storePointerUncheckedofObjectwithValue(0,0x10ff385d0,nilObj) > (sqInt) $5 = 4478138592 > (lldb) expr checkForLeaks = 0 > (sqInt) $0 = 0 > (lldb) c > > > and then save the image. > >> >>> >>> I also realized the VM I had was from this summer (the one that comes with a 70 image with zeroconf). The output files I include were produced by the VM at get.pharo.org/64/vmLatest70 >>> >>> https://www.dropbox.com/s/y8yqjuzd9nsvy1u/clap-broken.tar.gz?dl=0 >>> >>> On 20 March 2018 at 18:17, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>>> >>>> >>>> Hi Damien, >>>> >>>> On Tue, Mar 20, 2018 at 3:12 AM, Damien Pollet <damien.pollet(a)gmail.com> wrote: >>>>> >>>>> >>>>> Hi, I have a Pharo image that crashes the VM on startup. The crash report below seems to incriminate GC. Should I make it available somewhere online? What's most convenient? >>>> >>>> >>>> Don't care. Anywhere it can be downloaded from. Also, try running with -leakcheck 15, preferably in an assert VM and see if that gets you additional information. >>>> >>>>> >>>>> >>>>> Process: Pharo [64892] >>>>> Path: /Users/USER/*/Pharo.app/Contents/MacOS/Pharo >>>>> Identifier: org.pharo.Pharo >>>>> Version: 5.0.201708271955 (5.0.201708271955) >> >> >> Right. This VM is prior to the bug fixes in VMMaker.oscog-eem.2320: >> >> Spur: >> Fix a bad bug in SpurPlnningCompactor. unmarkObjectsFromFirstFreeObject, used when the compactor requires more than one pass due to insufficient savedFirstFieldsSpace, expects the corpse of a moved object to be unmarked, but copyAndUnmarkObject:to:bytes:firstField: only unmarked the target. Unmarking the corpse before the copy unmarks both. This fixes a crash with ReleaseBuilder class>>saveAsNewRelease when non-use of cacheDuring: creates lots of files, enough to push the system into the multi-pass regime. >> >> >> Pharo urgently needs to upgrade the VM to one more up to date than 2017 08 27 (in fact more up-to-date than opensmalltalk/vm commit 0fe1e1ea108e53501a0e728736048062c83a66ce, Fri Jan 19 13:17:57 2018 -0800). The bug that VMMaker.oscog-eem.2320 fixes can result in image corruption in large images, and can occur (as it has here) at start-up, causing one's work to be irretrievably lost. >> >>>>> >>>>> Code Type: X86-64 (Native) >>>>> Parent Process: ??? [64888] >>>>> Responsible: Pharo [64892] >>>>> User ID: 501 >>>>> >>>>> Date/Time: 2018-03-19 20:27:03.906 +0100 >>>>> OS Version: Mac OS X 10.13.3 (17D102) >>>>> Report Version: 12 >>>>> Anonymous UUID: 6D022236-78DD-6676-117F-EADA56D5D1BE >>>>> >>>>> Sleep/Wake UUID: AC9E4E55-3CDB-4B4F-A6B4-51ACB1177154 >>>>> >>>>> Time Awake Since Boot: 28000 seconds >>>>> Time Since Wake: 6500 seconds >>>>> >>>>> System Integrity Protection: enabled >>>>> >>>>> Crashed Thread: 0 Dispatch queue: com.apple.main-thread >>>>> >>>>> Exception Type: EXC_BAD_ACCESS (SIGABRT) >>>>> Exception Codes: KERN_INVALID_ADDRESS at 0x000000012b67c0b0 >>>>> Exception Note: EXC_CORPSE_NOTIFY >>>>> >>>>> VM Regions Near 0x12b67c0b0: >>>>> VM_ALLOCATE 000000011adfc000-00000001259fc000 [172.0M] rw-/rwx SM=PRV >>>>> --> >>>>> STACK GUARD 0000700005613000-0000700005614000 [ 4K] ---/rwx SM=NUL stack guard for thread 1 >>>>> >>>>> Application Specific Information: >>>>> abort() called >>>>> >>>>> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread >>>>> 0 libsystem_kernel.dylib 0x00007fff53fbde3e __pthread_kill + 10 >>>>> 1 libsystem_pthread.dylib 0x00007fff540fc150 pthread_kill + 333 >>>>> 2 libsystem_c.dylib 0x00007fff53f1a312 abort + 127 >>>>> 3 org.pharo.Pharo 0x0000000104ed8997 sigsegv + 190 >>>>> 4 libsystem_platform.dylib 0x00007fff540eff5a _sigtramp + 26 >>>>> 5 ??? 000000000000000000 0 + 0 >>>>> 6 org.pharo.Pharo 0x0000000104e73558 markObjects + 464 >>>>> 7 org.pharo.Pharo 0x0000000104e72d40 fullGC + 72 >>>>> 8 org.pharo.Pharo 0x0000000104e92dea primitiveFullGC + 45 >>>>> 9 org.pharo.Pharo 0x0000000104e52425 interpret + 26715 >>>>> 10 org.pharo.Pharo 0x0000000104e5c7f6 enterSmalltalkExecutiveImplementation + 152 >>>>> 11 org.pharo.Pharo 0x0000000104e4be6c interpret + 674 >>>>> 12 org.pharo.Pharo 0x0000000104ed9cc1 -[sqSqueakMainApplication runSqueak] + 394 >>>>> 13 com.apple.Foundation 0x00007fff2e6d696c __NSFirePerformWithOrder + 360 >>>>> 14 com.apple.CoreFoundation 0x00007fff2c579127 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 23 >>>>> 15 com.apple.CoreFoundation 0x00007fff2c57904f __CFRunLoopDoObservers + 527 >>>>> 16 com.apple.CoreFoundation 0x00007fff2c55b6a8 __CFRunLoopRun + 1240 >>>>> 17 com.apple.CoreFoundation 0x00007fff2c55af43 CFRunLoopRunSpecific + 483 >>>>> 18 com.apple.HIToolbox 0x00007fff2b872e26 RunCurrentEventLoopInMode + 286 >>>>> 19 com.apple.HIToolbox 0x00007fff2b872a9f ReceiveNextEventCommon + 366 >>>>> 20 com.apple.HIToolbox 0x00007fff2b872914 _BlockUntilNextEventMatchingListInModeWithFilter + 64 >>>>> 21 com.apple.AppKit 0x00007fff29b3df5f _DPSNextEvent + 2085 >>>>> 22 com.apple.AppKit 0x00007fff2a2d3b4c -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3044 >>>>> 23 com.apple.AppKit 0x00007fff29b32d6d -[NSApplication run] + 764 >>>>> 24 com.apple.AppKit 0x00007fff29b01f1a NSApplicationMain + 804 >>>>> >>>>> -- >>>>> Damien Pollet >>>>> type less, do more [ | ] http://people.untyped.org/damien.pollet >>>>> >>>> >>>> >>>> >>>> -- >>>> _,,,^..^,,,_ >>>> best, Eliot >>>> >>> >>> >>> >>> -- >>> Damien Pollet >>> type less, do more [ | ] http://people.untyped.org/damien.pollet >>> >> >> >> >> -- >> _,,,^..^,,,_ >> best, Eliot > > > > > -- > _,,,^..^,,,_ > best, Eliot

June 3, 2019

Re: [Pharo-dev] Default line endings while writing to a file stream

by Guillermo Polito

> El 2 jun 2019, a las 20:45, ducasse <stepharo(a)netcourrier.com> escribiÃ³: > > Sven > > why not having this as extension. Iâd even propose to have it by default: a FileReference writeStream can return a ZnNewLineWriterStream wrapping the corresponding stream. By default it can be configured with the systemâs default line ending convention (least surprise?). And then users can change it accordinglyâ¦ Now I ask also myself what we could do when reading line endings from a file. Iâm 98.761% convinced that in the image we should have a single line ending convention for strings, and that we should convert internal strings to the external representation of convenience explicitly. In this direction we could make that default read streams in FileSystem to automatically transform external line endings into internal line endings. > > Stef > > >> On 2 Jun 2019, at 13:52, Alistair Grant <akgrant0710(a)gmail.com> wrote: >> >> Hi Ben, >> >> On Fri, 31 May 2019 at 07:08, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> >>> I'm on Windows wanting to write a text file with LF endings. >>> The code developed on Linux is thus... >>> (destinationDirectory / 'README.md') ensureCreateFile >>> writeStreamDo: [ :stream | stream nextPutAll: class comment ] >> >> I've come across this so many times that I always add a couple of >> methods to my image: >> >> ZnEncodedStream>>asNewLineStream >> "Answer the receiver wrapped with a ZnNewLineWriterStream" >> ^ZnNewLineWriterStream on: self! ! >> >> >> ZnNewLineWriterStream>>asNewLineStream >> "Answer the receiver wrapped with a ZnNewLineWriterStream" >> ^self! ! >> >> >> You could then modify the example above to be: >> >> stream asNewLineStream forLf nextPutAll: class comment >> >> Cheers, >> Alistair >> >> >> >>> and I am stuck with CR line endings. >>> The specific symptom is that it screws `git diff` >>> Here is a simple experiment... >>> testfile := 'README.md' asFileReference. >>> testfile ensureCreateFile writeStreamDo: [ :stream | >>> stream nextPutAll: 'aa >>> bb' ]. >>> testfile binaryReadStream contents at: 3 "==> Character cr " >>> >>> I think its safe to assume on Linux that will result in "==> Character lf " >>> but can someone please confirm? >>> >>> So my issue is that I've got >>> #ensureCreateFile - returns a FileReference >>> and >>> :stream - is a ZnCharacterWriteStream wrapping a ZnBufferedWriteStream wrapping BinaryFileStream. >>> >>> and neither seem to have an easily accessible defaultLineEnding setting. >>> Indeed, line endings are not a property of FileReference >>> and Binary & Characters have nothing to do with line endings, >>> and questionable if Buffering is related. >>> >>> Its more a property of a File, but IIUC that is being deprecated (??) >>> >>> MultiByteFileStream has #lineEndConvention: >>> but IIUC that also is being deprecated. >>> >>> So what is the proper way to force default line endings? >>> >>> >>> ------ >>> Now while composing this email I discovered String>>withUnixLineEndings. >>> So I have a solution... >>> testfile := 'README.md' asFileReference. >>> testfile ensureCreateFile writeStreamDo: [ :stream | >>> stream nextPutAll: 'aa >>> bb' withUnixLineEndings ]. >>> (testfile binaryReadStream contents at: 3) asCharacter "==> Character lf " >>> >>> but that seems to imply that on Windows... >>> 'aa >>> bb' at: 3 "==> Character cr " >>> >>> and on Linux (someone please confirm)... >>> 'aa >>> bb' at: 3 "==> Character lf " >>> >>> and that is *very* curious. Strange that I never noticed it before and obviously that hasn't hurt me, >>> but considering the Principal Of Least Surprise it leaves me feeling somewhat violated :) >> > > >

June 2, 2019

[Pharo 8.0] Build #308: 3447-hex-deserves-an-executable-comment

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #308 was: SUCCESS. The Pull Request #3448 was integrated: "3447-hex-deserves-an-executable-comment" Pull request url: https://github.com/pharo-project/pharo/pull/3448 Issue Url: https://github.com/pharo-project/pharo/issues/3447 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

June 2, 2019

Re: [Pharo-dev] Default line endings while writing to a file stream

by ducasse

Sven why not having this as extension. Stef > On 2 Jun 2019, at 13:52, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Ben, > > On Fri, 31 May 2019 at 07:08, Ben Coman <btc(a)openinworld.com> wrote: >> >> >> I'm on Windows wanting to write a text file with LF endings. >> The code developed on Linux is thus... >> (destinationDirectory / 'README.md') ensureCreateFile >> writeStreamDo: [ :stream | stream nextPutAll: class comment ] > > I've come across this so many times that I always add a couple of > methods to my image: > > ZnEncodedStream>>asNewLineStream > "Answer the receiver wrapped with a ZnNewLineWriterStream" > ^ZnNewLineWriterStream on: self! ! > > > ZnNewLineWriterStream>>asNewLineStream > "Answer the receiver wrapped with a ZnNewLineWriterStream" > ^self! ! > > > You could then modify the example above to be: > > stream asNewLineStream forLf nextPutAll: class comment > > Cheers, > Alistair > > > >> and I am stuck with CR line endings. >> The specific symptom is that it screws `git diff` >> Here is a simple experiment... >> testfile := 'README.md' asFileReference. >> testfile ensureCreateFile writeStreamDo: [ :stream | >> stream nextPutAll: 'aa >> bb' ]. >> testfile binaryReadStream contents at: 3 "==> Character cr " >> >> I think its safe to assume on Linux that will result in "==> Character lf " >> but can someone please confirm? >> >> So my issue is that I've got >> #ensureCreateFile - returns a FileReference >> and >> :stream - is a ZnCharacterWriteStream wrapping a ZnBufferedWriteStream wrapping BinaryFileStream. >> >> and neither seem to have an easily accessible defaultLineEnding setting. >> Indeed, line endings are not a property of FileReference >> and Binary & Characters have nothing to do with line endings, >> and questionable if Buffering is related. >> >> Its more a property of a File, but IIUC that is being deprecated (??) >> >> MultiByteFileStream has #lineEndConvention: >> but IIUC that also is being deprecated. >> >> So what is the proper way to force default line endings? >> >> >> ------ >> Now while composing this email I discovered String>>withUnixLineEndings. >> So I have a solution... >> testfile := 'README.md' asFileReference. >> testfile ensureCreateFile writeStreamDo: [ :stream | >> stream nextPutAll: 'aa >> bb' withUnixLineEndings ]. >> (testfile binaryReadStream contents at: 3) asCharacter "==> Character lf " >> >> but that seems to imply that on Windows... >> 'aa >> bb' at: 3 "==> Character cr " >> >> and on Linux (someone please confirm)... >> 'aa >> bb' at: 3 "==> Character lf " >> >> and that is *very* curious. Strange that I never noticed it before and obviously that hasn't hurt me, >> but considering the Principal Of Least Surprise it leaves me feeling somewhat violated :) >

June 2, 2019

Re: [Pharo-dev] Versioning with Iceberg

by ducasse

> On 2 Jun 2019, at 20:19, Shaping <shaping(a)uurda.org> wrote: > > [â¦] I prefer the more detailed syntax highlighting in VW. > > Check the styler look for <style> in Pharo because you can create your own. > > I donât see this in Settings. I see âSyntax Highlightingâ¦â It is not exposed in the settings. Probably because it had its own preferences and we should migrate it. I created the issue: https://github.com/pharo-project/pharo/issues/3449 Now we will see if we succeed to find the time to work on it. Check SHRBTextStyler <styleTable: â¦> here is the default style blueStyleTable "color can be a valid argument to Color class>>colorFrom: , or nil to use the editor text color. Multiple emphases can be specified using an array e.g. #(bold italic). If emphasis is not specified, #normal will be used. if pixel height is not specified , then the editor font size will be used. " <styleTable: 'Blue'> ^ #( "(symbol color [emphasisSymbolOrArray [textStyleName [pixelHeight]]])" (default black) (invalid red) (excessCode red) (comment (gray darker)) (unfinishedComment (red muchDarker)) (#'$' (red muchDarker)) (character (red muchDarker)) (integer (red muchDarker)) (number (red muchDarker)) (#- (red muchDarker)) (symbol (magenta muchDarker)) (stringSymbol (magenta muchDarker)) (literalArray (magenta muchDarker)) (string (magenta muchDarker) normal) (unfinishedString red normal) (assignment nil) (ansiAssignment nil) (literal nil italic) (keyword (black)) (binary (black)) (unary (black)) (#self (cyan muchDarker )) (#super (cyan muchDarker )) (#true (red muchDarker)) (#false (red muchDarker)) (#nil (red muchDarker)) (#thisContext (cyan muchDarker )) (#return (cyan muchDarker ) bold) (patternArg (blue muchDarker)) (methodArg (blue muchDarker)) (blockPatternArg (blue muchDarker)) (blockArg (blue muchDarker)) (argument (blue muchDarker)) (blockTempVar (blue muchDarker)) (blockPatternTempVar (blue muchDarker)) (instVar (blue muchDarker)) (workspaceVar (blue muchDarker)) (tempVar (blue muchDarker)) (patternTempVar (blue muchDarker)) (poolConstant (blue muchDarker)) (classVar (blue muchDarker)) (globalVar (blue muchDarker)) (incompleteIdentifier blue italic) (incompleteKeyword nil italic) (incompleteBinary nil italic) (incompleteUnary nil italic) (undefinedIdentifier red) (undefinedKeyword red) (undefinedBinary red) (undefinedUnary red) (patternKeyword nil bold) (patternBinary nil bold) (patternUnary nil bold) (blockArgColon black) (leftParenthesis black) (rightParenthesis black) (leftParenthesis1 (green muchDarker)) (rightParenthesis1 (green muchDarker)) (leftParenthesis2 (magenta muchDarker)) (rightParenthesis2 (magenta muchDarker)) (leftParenthesis3 (red muchDarker)) (rightParenthesis3 (red muchDarker)) (leftParenthesis4 (green darker)) (rightParenthesis4 (green darker)) (leftParenthesis5 (orange darker)) (rightParenthesis5 (orange darker)) (leftParenthesis6 (magenta darker)) (rightParenthesis6 (magenta darker)) (leftParenthesis7 blue) (rightParenthesis7 blue) (blockStart black) (blockEnd black) (blockStart1 (green muchDarker)) (blockEnd1 (green muchDarker)) (blockStart2 (magenta muchDarker)) (blockEnd2 (magenta muchDarker)) (blockStart3 (red muchDarker)) (blockEnd3 (red muchDarker)) (blockStart4 (green darker)) (blockEnd4 (green darker)) (blockStart5 (orange darker)) (blockEnd5 (orange darker)) (blockStart6 (magenta darker)) (blockEnd6 (magenta darker)) (blockStart7 blue) (blockEnd7 blue) (arrayStart black) (arrayEnd black) (arrayStart1 black) (arrayEnd1 black) (leftBrace black) (rightBrace black) (cascadeSeparator black) (statementSeparator black) (methodTempBar (black)) (blockTempBar (black)) (blockArgsBar (black)) (externalCallType black) (externalCallTypePointerIndicator black) (primitiveOrExternalCallStart black bold) (primitiveOrExternalCallEnd black bold) (primitive (green muchDarker)) (pragmaKeyword (green muchDarker)) (pragmaUnary (green muchDarker)) (pragmaBinary (green muchDarker)) (externalFunctionCallingConvention (green muchDarker) bold) (module (green muchDarker) bold)) > > We need to do one for the dark theme. > There are a lot of variations. > >> I forgot all the differences, but recall more levels of parentheses can be colored uniquely in VW and so can block-argument variables. That would be a first small project: make Pharo syntax highlight at least as good as VWâs. I need to do the same for formatting, which I've not checked out very thoroughly yet. > > For formatting check the BIformatter. > > I cannot find class BIFormatter in the 7.0.3 image. What must I load? BIConfigurableFormatter is in the image. You have it in the settings. > > > We are working on > - adding tests (we have about 150 tests ready to get integrated > - working on a new tool to see and understand the settings > - we want to make sure that we can pretty print the complete system > so we will come probably with an extended pretty printer. > > Sounds good. > >> The other thing that has been causing problems and about which I've written some examples in Fogbugz (which no one is using anymore for Paroâand I didnât know, lol) is that Pharo labels are truncated if you switch to a monospace font. I can't see what I'm doing some of the time because the labels are chopped, and there is no automatic formatting of the fields to accommodate the new font, which is not even very big--just normal-sized monospace. I suppose Spec takes care of this problem systematically and that this is why nothing else has been done to fix the problem. > > Yes this is super annoying. Can you check with Spec 20 and this should be fixed. > > Iâm not sure what Spec 20 is. Are you referring to this document in progress: > This document is just the description of the integration of Commander2 with Spec20. Spec20 has examples. Check SpecDemo Check the examples in Spec-Examples. but I just see that latest version is frrezing the image :( > https://travis-ci.com/SquareBracketAssociates/BuildingApplicationWithSpec2 <https://travis-ci.com/SquareBracketAssociates/BuildingApplicationWithSpec2> > > ? >

June 2, 2019

SpecDemo open freezes the system ...

by ducasse

In latest P8

June 2, 2019

Re: [Pharo-dev] Iceberg: No Project Founds

by Shaping

On 2 Jun 2019, at 19:22, Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org> > wrote: >From a 64-bit Pharo 7.0.3 I cloned UpdatedPharoByExample and immediately saw in red âNo Project Foundâ. Why is this and what must I do to fix it? GitKraken shows that the repo is healthy. But what are you clone a book repo only containing pillar file? Iceberg right now manages code. Right, I thought there were code examples in the project and that this would be enough for Iceberg to work with it. Try to clone of my Containers-Stack repo to see. The name of the GitHub repo to clone isâ¦? Shaping

June 2, 2019

Re: [Pharo-dev] Environments

by Shaping

Is the sequence: dev, alpha, beta, release? no alpha=dev Okay. We are working on Modules for Pharo now this is tricky and it can impact the complete system. Yes, it is very tricky and can cause chaos and destroy much utility if not managed correctly. Since Squeak3.9 Iâm working on removing hardocded usage of Smalltalk instead of an environment or se;lf class environment. So that one day we can try module/namespace for real. Now when porting code from VW to Pharo 1.0 :) I just did a mapping namespace to prefix and change the class name in VW to have prefixName. This is basically what the exporters are doing from VW. Right. I donât see Spec2 in Pharo 8. I suppose I need to load it. No it is directly in. In a virgin 8.0 dev image I see refs to âSpecâ in Packages but not to âSpec2â. Is the Spec book still relevant? Not fully we will start to port the book. Okay. Is Spec2 mostly about the back-end changes for use of GTK? No it is a massive change. - Introducing new layouts (deprecated the interpreter design) - soon using Commander2 for menus and the rest - many many cleans - Introduction of application and more. Okay, sounds good. Shaping

June 2, 2019

Re: [Pharo-dev] Versioning with Iceberg

by Shaping

[â¦] I prefer the more detailed syntax highlighting in VW. Check the styler look for <style> in Pharo because you can create your own. I donât see this in Settings. I see âSyntax Highlightingâ¦â We need to do one for the dark theme. There are a lot of variations. I forgot all the differences, but recall more levels of parentheses can be colored uniquely in VW and so can block-argument variables. That would be a first small project: make Pharo syntax highlight at least as good as VWâs. I need to do the same for formatting, which I've not checked out very thoroughly yet. For formatting check the BIformatter. I cannot find class BIFormatter in the 7.0.3 image. What must I load? We are working on - adding tests (we have about 150 tests ready to get integrated - working on a new tool to see and understand the settings - we want to make sure that we can pretty print the complete system so we will come probably with an extended pretty printer. Sounds good. The other thing that has been causing problems and about which I've written some examples in Fogbugz (which no one is using anymore for Paroâand I didnât know, lol) is that Pharo labels are truncated if you switch to a monospace font. I can't see what I'm doing some of the time because the labels are chopped, and there is no automatic formatting of the fields to accommodate the new font, which is not even very big--just normal-sized monospace. I suppose Spec takes care of this problem systematically and that this is why nothing else has been done to fix the problem. Yes this is super annoying. Can you check with Spec 20 and this should be fixed. Iâm not sure what Spec 20 is. Are you referring to this document in progress: https://travis-ci.com/SquareBracketAssociates/BuildingApplicationWithSpec2 ? Now the font logic is one of the few parts that we did not revisit yet but it is not way it should. Also may users hardcode standardFontsâ¦.( the ugly singleton strike back). Are you aware of "extension methods" ? Where a method you add to a built-in Pharo class (Collection for example) is saved/loaded with your package. Then you only need to manage your package not Pharo built-in packages as well. Yes, I'm trying to get an Iceberg-on-Git groove going so that I can make my own packages for extensions/overrides. yes us know we can also do some screen sharing with you to get you up to speed. [..] Cloning the Pharo Track repo from the command line is done like this... $ git clone <mailto:git@github.com:exercism/pharo-smalltalk.git> git@github.com:exercism/pharo-smalltalk.git Sure, but we can do this in Icebergâand it works. So why use the command line? which creates a folder with the same name as the repo (i.e. "pharo-smalltalk") As a git GUI, Iceberg does the same. Indeed, Iceberg uses libgit2 to do this, so the behaviour is standard git. I was commenting on the ergonomics, and yes this is very much a Git thing. Git is bad :) but this is the way to go. The API sucks. Yes, it has terminology problems too. Shaping

June 2, 2019