- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] About file printOn: method

by Udo Schneider

Hi Stef, once upon in time :-) I picked up the notion that #printString "should" return a string which (when executed) results in the printed object. Whereras #displayString is "nicer" for the user. Not quite sure if this still applies though. But in this regard what about something like fr1 := FileSystem disk root / 'folder' / 'file.txt'. fr2 := FileSystem memory root / 'folder' / 'file.txt'. fr1 printString. "FileSystem // 'file:///folder/file.txt'" fr2 printString. "FileSystem // 'memory:///folder/file.txt'" fr1 displayString. "'file:///folder/file.txt'" fr2 displayString. "'memory:///folder/file.txt'" For FileReferences which use a FileSystem with a configured Store those settings could be added to the URL as host/query. E.g. for a WebDav FileReference: #printString "FileSystem // 'webdav://uid:pwd@host/folder/file.txt&usePatch=false'" #displayString "'webdav://uid:pwd@host/folder/file.txt'" CU, Udo On 09/09/16 20:34, stepharo wrote: > Hi Udo > > Thanks for the suggestion. It means that the printOn: should really > involve the FieSystem and this is probably right. > Now the point of the printOn: vs the displayString is that we can get > back an object and right now we get a string :) > Your URI suggestion should be applied to the displayString or the > asFileReference should understand it. > I added your feedback to the entry. > > Stef > > Le 9/9/16 Ã 20:19, Udo Schneider a Ã©crit : >> I'm a bit biased on this. IMHO this simplification in the #printString >> (which I quite like BTW!) is only applicable to Files in DiskFileSystem. >> >> If you have a FileReference on a non disk filesystem (e.g. >> >> fr1 := FileSystem memory root / 'folder' / 'test.txt'. >> "memory:///folder/test.txt" >> >> on use this simplified #printString you'll end up with >> >> '/folder/test.txt' asFileReference. >> >> This might be confusing as this does not mention the filesystem. So >> you might end up creating a new instance via >> >> fr2 := '/folder/test.txt' asFileReference. >> >> which is not equal to the original fileRef: >> >> fr1 = fr2 "false" >> >> As I do like the #printString simplification ... why not simply adopt >> a URI style scheme for FileReferences. This would allow encoding the >> filesystem type (e.g. file://, memory://, zip://, s3://) including >> parameters like host if needed and of course the path. >> >> CU, >> >> Udo >> >> >> >> On 04/09/16 09:47, stepharo wrote: >>> It is raining and I will do it :) >>> >>> >>> stef >>> >>> >>> Le 4/9/16 Ã 02:38, monty a Ã©crit : >>>> +1 >>>> >>>>> Sent: Saturday, September 03, 2016 at 10:39 AM >>>>> From: stepharo <stepharo(a)free.fr> >>>>> To: "Pharo Development List" >>>>> <pharo-dev(a)lists.pharo.org> >>>>> Subject: [Pharo-dev] About file printOn: method >>>>> >>>>> Hi >>>>> >>>>> >>>>> I will implement the following because this is too annoying. >>>>> >>>>> currently >>>>> >>>>> 'tmp/foo.txt' asFileReference >>>>> > >>>>> File @ tmp/foo.txt >>>>> >>>>> and it would be much much better to get back >>>>> 'tmp/foo.txt' asFileReference >>>>> >>>>> So that we can get >>>>> { 'tmp/foo.txt' asFileReference } >>>>> > { 'tmp/foo.txt' asFileReference } >>>>> >>>>> and not >>>>> "an Array(File @ tmp/foo.txt)" >>>>> >>>>> >>>>> In addition we should turn the current printOn: method into a >>>>> displayString method so that >>>>> a list of fileReference can be well display with File @ tmp/foo.txt >>>>> for >>>>> example >>>>> >>>>> >>>>> https://pharo.fogbugz.com/f/cases/18956 >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> >> >> >> > > >

Sept. 9, 2016

Re: [Pharo-dev] About file printOn: method

by stepharo

Hi Udo Thanks for the suggestion. It means that the printOn: should really involve the FieSystem and this is probably right. Now the point of the printOn: vs the displayString is that we can get back an object and right now we get a string :) Your URI suggestion should be applied to the displayString or the asFileReference should understand it. I added your feedback to the entry. Stef Le 9/9/16 Ã 20:19, Udo Schneider a Ã©crit : > I'm a bit biased on this. IMHO this simplification in the #printString > (which I quite like BTW!) is only applicable to Files in DiskFileSystem. > > If you have a FileReference on a non disk filesystem (e.g. > > fr1 := FileSystem memory root / 'folder' / 'test.txt'. > "memory:///folder/test.txt" > > on use this simplified #printString you'll end up with > > '/folder/test.txt' asFileReference. > > This might be confusing as this does not mention the filesystem. So > you might end up creating a new instance via > > fr2 := '/folder/test.txt' asFileReference. > > which is not equal to the original fileRef: > > fr1 = fr2 "false" > > As I do like the #printString simplification ... why not simply adopt > a URI style scheme for FileReferences. This would allow encoding the > filesystem type (e.g. file://, memory://, zip://, s3://) including > parameters like host if needed and of course the path. > > CU, > > Udo > > > > On 04/09/16 09:47, stepharo wrote: >> It is raining and I will do it :) >> >> >> stef >> >> >> Le 4/9/16 Ã 02:38, monty a Ã©crit : >>> +1 >>> >>>> Sent: Saturday, September 03, 2016 at 10:39 AM >>>> From: stepharo <stepharo(a)free.fr> >>>> To: "Pharo Development List" >>>> <pharo-dev(a)lists.pharo.org> >>>> Subject: [Pharo-dev] About file printOn: method >>>> >>>> Hi >>>> >>>> >>>> I will implement the following because this is too annoying. >>>> >>>> currently >>>> >>>> 'tmp/foo.txt' asFileReference >>>> > >>>> File @ tmp/foo.txt >>>> >>>> and it would be much much better to get back >>>> 'tmp/foo.txt' asFileReference >>>> >>>> So that we can get >>>> { 'tmp/foo.txt' asFileReference } >>>> > { 'tmp/foo.txt' asFileReference } >>>> >>>> and not >>>> "an Array(File @ tmp/foo.txt)" >>>> >>>> >>>> In addition we should turn the current printOn: method into a >>>> displayString method so that >>>> a list of fileReference can be well display with File @ tmp/foo.txt >>>> for >>>> example >>>> >>>> >>>> https://pharo.fogbugz.com/f/cases/18956 >>>> >>>> >>>> >>> >> >> >> > > > >

Sept. 9, 2016

Re: [Pharo-dev] About file printOn: method

by Udo Schneider

I'm a bit biased on this. IMHO this simplification in the #printString (which I quite like BTW!) is only applicable to Files in DiskFileSystem. If you have a FileReference on a non disk filesystem (e.g. fr1 := FileSystem memory root / 'folder' / 'test.txt'. "memory:///folder/test.txt" on use this simplified #printString you'll end up with '/folder/test.txt' asFileReference. This might be confusing as this does not mention the filesystem. So you might end up creating a new instance via fr2 := '/folder/test.txt' asFileReference. which is not equal to the original fileRef: fr1 = fr2 "false" As I do like the #printString simplification ... why not simply adopt a URI style scheme for FileReferences. This would allow encoding the filesystem type (e.g. file://, memory://, zip://, s3://) including parameters like host if needed and of course the path. CU, Udo On 04/09/16 09:47, stepharo wrote: > It is raining and I will do it :) > > > stef > > > Le 4/9/16 Ã 02:38, monty a Ã©crit : >> +1 >> >>> Sent: Saturday, September 03, 2016 at 10:39 AM >>> From: stepharo <stepharo(a)free.fr> >>> To: "Pharo Development List" >>> <pharo-dev(a)lists.pharo.org> >>> Subject: [Pharo-dev] About file printOn: method >>> >>> Hi >>> >>> >>> I will implement the following because this is too annoying. >>> >>> currently >>> >>> 'tmp/foo.txt' asFileReference >>> > >>> File @ tmp/foo.txt >>> >>> and it would be much much better to get back >>> 'tmp/foo.txt' asFileReference >>> >>> So that we can get >>> { 'tmp/foo.txt' asFileReference } >>> > { 'tmp/foo.txt' asFileReference } >>> >>> and not >>> "an Array(File @ tmp/foo.txt)" >>> >>> >>> In addition we should turn the current printOn: method into a >>> displayString method so that >>> a list of fileReference can be well display with File @ tmp/foo.txt for >>> example >>> >>> >>> https://pharo.fogbugz.com/f/cases/18956 >>> >>> >>> >> > > >

Sept. 9, 2016

Rubric set text without undorecord

by Nicolai Hess

Anyone knows how to set the text in a rub text model without generating an undorecord? Right now, opening a message browser and scrolling through the lists of entries updates the text on the code pane and every update will create a new undorecord. I would prefer if the undorecord is only generated when *editing* a method. nicolai

Sept. 9, 2016

Re: [Pharo-dev] typedef pointerArity for FFIOpaqueObjects

by Esteban Lorenzano

Hi Ben, here you do not need to use an opaque object (is not that what you want). in this case you have two paths to follow: 1) you just declare CXIndex as an alias of ExternalAddress (or void*). This will work but is not cool because UFFI will answer you an ExternalAddress and probably you want to treat CXIndex as an object. 2) then you need to declare CXIndex as FFIExternalObject (not OpaqueObject). FFIExternalObject subclass: #CXIndex. this will work as you expected. Opaque objects are structures that you do not care content, so it is not what you wan here: https://en.wikipedia.org/wiki/Opaque_data_type instead FFIExternalObject is precisely meant to manage pointer types (and you do not need to do all that hacking around). cheers, Esteban > On 09 Sep 2016, at 16:53, Ben Coman <btc(a)openInWorld.com> wrote: > > I have a type definition... > typedef void *CXIndex; > > which I believe reads "CXIndex is a pointer at void" > that is returned by... > CXIndex clang_createIndex(int x, int y) > > This seems an obvious candidate to be a FFIOpaqueObject defined like this... > > FFIOpaqueObject subclass: #CXIndex > instanceVariableNames: '' > classVariableNames: '' > package: 'LibclangPractice' > > CXIndex class >> create > ^ self ffiCall: #( CXIndex clang_createIndex ( 0, 0 ) ) > > however "CXIndex create inspect" > produces an error ==> FFIDereferencedOpaqueObjectError. > because..."external objects have a natural arity of zero but they MUST be called with some arity, > because they are actually external addresses (pointers) and you need to always declare external objects as this example: > self ffiCall: #( FFIExternalObject *c_function ( FFIExternalObject *handle ) ) > " > > which is enforced by... > FFIOpaqueObjectType>>validateAfterParse: typeAndArityTuple > self pointerArity >= 1 ifTrue: [ ^ self ]. "@0" > typeAndArityTuple second >= 1 ifTrue: [ ^ self ]. > FFIDereferencedOpaqueObjectError signal > > > where pointerArity seems set earlier just by counting the number of pointer stars in the functions return type, which in this case is none... > FFICallout>>resolveType: aTypeName "aTypeName==> 'CXIndex' " > | name newName resolver binding ptrArity | > newName := aTypeName. > ptrArity := 0. > "resolve aliases and pointers" > [ > name := newName asString trimRight. > newName := self aliasForType: name. > newName last = $* ifTrue: [ > ptrArity := ptrArity + 1. > newName := newName allButLast ]. > name = newName > ] whileFalse. > resolver := requestor ifNil: [ self class ]. "resolver==> CXIndex class" > binding := resolver ffiBindingOf: name asSymbol. "binding==> #CXIndex->CXIndex" > binding ifNotNil: [ > ^ (binding value "@1" asExternalTypeOn: self) "@2" pointerArity: ptrArity ] . > > which @1 invokes... > CXIndex(FFIOpaqueObject) class >> asExternalTypeOn: generator > ^ FFIOpaqueObjectType objectClass: self > > FFIOpaqueObjectType(FFIExternalReferenceType) class >> objectClass: aClass > ^ self new objectClass: aClass > > FFIOpaqueObjectType(FFIExternalReferenceType) >> objectClass: aClass > objectClass := aClass. "aClass==>CXIndex" > pointerArity := 0. "actually this was done in #initialize" "@3" > > > Thus FFIOpaqueObjectType(CXIndex) is returned @2 which invokes... > FFIOpaqueObjectType(FFIExternalType)>>pointerArity: additionalArity > pointerArity := pointerArity + additionalArity. > which sets pointerArity ==> 0. > > > But I hazard to suggest that... > typedef void *CXIndex; > > should make pointerArity:=1 when objectClass is assigned @3. > > > So I hacked around this by.... > FFIExternalReference class >> pointerArity > ^0 > > CXIndex class >> pointerArity > ^1 > > FFIExternalReferenceType >> objectClass: aClass > objectClass := aClass. > pointerArity := aClass pointerArity. > > but I wonder if this is the best way, or if external references these opaque objects should have a class-side method similar to #fieldDesc like... > typedef > ^#( void * ) > > Thus CXIndex create "==> a CXIndex((void*)@ 16rB6D514A8)" > > I am yet to test out this returned object by passing it to another C-library function, but I thought the above was enough for one sitting. > > cheers -ben > > > P.S. Further background... > > Declarations... > typedef void *CXIndex; > CXIndex clang_createIndex(int xx, int yy)); > defined at... > https://github.com/llvm-mirror/clang/blob/release_39/include/clang-c/Index.h <https://github.com/llvm-mirror/clang/blob/release_39/include/clang-c/Index.h> > > and definition is at... > https://github.com/llvm-mirror/clang/blob/release_39/include/clang-c/Index.h <https://github.com/llvm-mirror/clang/blob/release_39/include/clang-c/Index.h> > > extern "C" { > CXIndex clang_createIndex( ) { > ... > CIndexer *CIdxr = new CIndexer(); > ... > return CIndexer; > } } >

Sept. 9, 2016

Re: [Pharo-dev] SUnit improvements need review and feedback

by Denis Kudriashov

2016-09-09 18:09 GMT+02:00 stepharo <stepharo(a)free.fr>: > Tx denis. > > I wonder what is the reason of the crashes I experienced. > I don't know. Here is details on covered issue: TestExecutionEnvironment introduces problem when image is saved inside test process (which is case for Guille code which fork image inside test). And problem is that snapshot restarts all low level processes like IdlProcess, eventLoop and others (which are spawned in startup list). And when it happens inside test process all child processes are intercepted and terminated when test completes which means killing all system processes on test completes To fix it image snapshot should be always performed under default execution environment. (There is already another case like this: opening debugger to debug test. Debugger spawns new UI process and it should not be under test environment).

Sept. 9, 2016

Re: [Pharo-dev] SUnit improvements need review and feedback

by stepharo

Tx denis. I wonder what is the reason of the crashes I experienced. Le 9/9/16 Ã 18:01, Denis Kudriashov a Ã©crit : > And fix for Guille case is inbox 19073 > <https://pharo.fogbugz.com/f/cases/19073/Image-snapshot-should-be-forcible-e…>. > (details are inside) > > 2016-09-05 23:30 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com > <mailto:dionisiydk@gmail.com>>: > > > 2016-09-05 18:23 GMT+02:00 Guillermo Polito > <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>>: > > ARgh, since this got integrated I keep crashing images... > > I'm just executing some OSSubprocess like this: > > process := OSSUnixSubprocess new > command: 'ls'; > redirectStdout; > runAndWaitOnExitDo: [ :command :outString | ^ outString ]. > > and my image crashes with a: > > (scheduler could not find a runnable process) > > So this is messing up badly the scheduler. We have to fix this :/ > > > To disable this changes just replace runCaseManaged with runCase > in any senders. > It will approve is it related or not. > > But if crash happens not during tests then it should not be > related to this changes. > >

Sept. 9, 2016

Re: [Pharo-dev] SUnit improvements need review and feedback

by Denis Kudriashov

And fix for Guille case is inbox 19073 <https://pharo.fogbugz.com/f/cases/19073/Image-snapshot-should-be-forcible-e…>. (details are inside) 2016-09-05 23:30 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > > 2016-09-05 18:23 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > >> ARgh, since this got integrated I keep crashing images... >> >> I'm just executing some OSSubprocess like this: >> >> process := OSSUnixSubprocess new >> command: 'ls'; >> redirectStdout; >> runAndWaitOnExitDo: [ :command :outString | ^ outString ]. >> >> and my image crashes with a: >> >> (scheduler could not find a runnable process) >> >> So this is messing up badly the scheduler. We have to fix this :/ >> > > To disable this changes just replace runCaseManaged with runCase in any > senders. > It will approve is it related or not. > > But if crash happens not during tests then it should not be related to > this changes. >

Sept. 9, 2016

Re: [Pharo-dev] Ombu losing file on folder renaming

by stepharo

> Ah, it fails when using the absolute path, which doesn't exist > anymore...it would work by using a file locator , no? > I do not know but I suspect that at each session restart this path should be renewed. > El 8/9/2016 12:32, "Damien Pollet" <damien.pollet(a)gmail.com > <mailto:damien.pollet@gmail.com>> escribiÃ³: > > The path you copied corresponds to before, or after the rename ? > It was before the rename.

Sept. 9, 2016

Re: [Pharo-dev] Ombu losing file on folder renaming

by Martin Dias

Ah, it fails when using the absolute path, which doesn't exist anymore...it would work by using a file locator , no? El 8/9/2016 12:32, "Damien Pollet" <damien.pollet(a)gmail.com> escribiÃ³: > The path you copied corresponds to before, or after the rename ? > > On 8 September 2016 at 09:27, stepharo <stepharo(a)free.fr> wrote: > >> Hi Martin >> >> I often get >> >> Information >> Ombu: Couldn't write entry, since FileDoesNotExist: File @ >> /Users/ducasse/Workspace/FirstCircle/ActiveResearch/Pharo/Ph >> aroHarvestingFixes/60/current/pharo-local/ombu-sessions/Phar >> o_ajxqkxc.ombu >> >> And this happens when I save and close the image, renamed the folder and >> reopen the image. >> >> Stef >> >> >> >> > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet >

Sept. 9, 2016