Re: [Pharo-dev] [pharo-project/pharo-core] 4d4f25: 40358
Marcus we could have turn the rule to the inverse. Menu item should not get translated. Stef On 6/11/14 20:28, GitHub wrote: 14409 remove RBTranslateLiteralsInMenusRule https://pharo.fogbugz.com/f/cases/14409
[Pharo-dev] [update 3.0] #30860
30860 - 14405 (backport pharo3) FileOut creates invalid comment entries for classes with class side methods https://pharo.fogbugz.com/f/cases/14405
Re: [Pharo-dev] [Vm-dev] Re: PharoVM - Build issues on CentOS6.5
2014-11-07 10:40 GMT+01:00 p...@highoctane.be p...@highoctane.be: I removed the thirdparty things for libs like ssl sdl etc. Now, things are building. What to do to get these externals to work? Phil more recent cmake version ? https://www.mail-archive.com/pharo-dev@lists.pharo.org/msg20781.html
Re: [Pharo-dev] [Vm-dev] Re: PharoVM - Build issues on CentOS6.5
[philippeback@CENTOSDEV frontend]$ cmake --version cmake version 2.6-patch 4 Maybe. I did a yum upgrade cmake and now have $ cmake --version cmake version 2.8.12.2 Will try that out. Thx.
Re: [Pharo-dev] PharoVM - Build issues on CentOS6.5
No need as dependencies get loaded and built by the VM build process. Works now, it was the CMake version bump that was needed. Thx all for the help. (Can't we get a CentOS build slave???) Phil On Fri, Nov 7, 2014 at 10:55 AM, Christophe Demarey christophe.dema...@inria.fr wrote: Le 7 nov. 2014 à 10:40, p...@highoctane.be a écrit : I removed the thirdparty things for libs like ssl sdl etc. Now, things are building. What to do to get these externals to work? stupid question but did you try to install libssl, libsdl and co on your cent OS (using yum or whatever)?
Re: [Pharo-dev] PharoVM - Build issues on CentOS6.5
for now, you do not need those dependencies. I’m preparing the vm for use libgit2 with monticello (not ready yet) and to render UI using sdl2 through OSWindow (also not ready yet). In the future you will need them to improve your pharo experience, but for now you can safely skip it. nothing changed in the way cmake files are built, but previous versions didn’t have third party libraries for unix (now we have them). if cmake is failing to download the libraries, it can happen because some versions/distributions of cmake does not allow ssl downloads… no idea how to help there, maybe an updated cmake helps, maybe not. but cmake tries always to download first from http://files.pharo.org/vm/src/lib http://files.pharo.org/vm/src/lib if it does not find it, maybe one interesting change is to add a previous check in some local repository (to do a simple copy instead a download). I can do that, but it will take some time, as always :) Esteban On 07 Nov 2014, at 11:10, p...@highoctane.be wrote: No need as dependencies get loaded and built by the VM build process. Works now, it was the CMake version bump that was needed. Thx all for the help. (Can't we get a CentOS build slave???) Phil On Fri, Nov 7, 2014 at 10:55 AM, Christophe Demarey christophe.dema...@inria.fr mailto:christophe.dema...@inria.fr wrote: Le 7 nov. 2014 à 10:40, p...@highoctane.be mailto:p...@highoctane.be a écrit : I removed the thirdparty things for libs like ssl sdl etc. Now, things are building. What to do to get these externals to work? stupid question but did you try to install libssl, libsdl and co on your cent OS (using yum or whatever)?
Re: [Pharo-dev] PharoVM - Build issues on CentOS6.5
Ok, understood. Now, if someone puts a CentOS 6.5 slave somewhere I can put the Jenkins job on it and bootstrap (as I do have a working CentOS VM to generate the sources). Phil On Fri, Nov 7, 2014 at 11:52 AM, Esteban Lorenzano esteba...@gmail.com wrote: for now, you do not need those dependencies. I’m preparing the vm for use libgit2 with monticello (not ready yet) and to render UI using sdl2 through OSWindow (also not ready yet). In the future you will need them to improve your pharo experience, but for now you can safely skip it. nothing changed in the way cmake files are built, but previous versions didn’t have third party libraries for unix (now we have them). if cmake is failing to download the libraries, it can happen because some versions/distributions of cmake does not allow ssl downloads… no idea how to help there, maybe an updated cmake helps, maybe not. but cmake tries always to download first from *http://files.pharo.org/vm/src/lib http://files.pharo.org/vm/src/lib *if it does not find it, maybe one interesting change is to add a previous check in some local repository (to do a simple copy instead a download). I can do that, but it will take some time, as always :) Esteban On 07 Nov 2014, at 11:10, p...@highoctane.be wrote: No need as dependencies get loaded and built by the VM build process. Works now, it was the CMake version bump that was needed. Thx all for the help. (Can't we get a CentOS build slave???) Phil On Fri, Nov 7, 2014 at 10:55 AM, Christophe Demarey christophe.dema...@inria.fr wrote: Le 7 nov. 2014 à 10:40, p...@highoctane.be a écrit : I removed the thirdparty things for libs like ssl sdl etc. Now, things are building. What to do to get these externals to work? stupid question but did you try to install libssl, libsdl and co on your cent OS (using yum or whatever)?
[Pharo-dev] [pharo-project/pharo-core] d6237a: 40360
Branch: refs/heads/4.0 Home: https://github.com/pharo-project/pharo-core Commit: d6237af950749d5cd9a8994eb1fc11c7fae874f9 https://github.com/pharo-project/pharo-core/commit/d6237af950749d5cd9a8994eb1fc11c7fae874f9 Author: Jenkins Build Server bo...@pharo-project.org Date: 2014-11-07 (Fri, 07 Nov 2014) Changed paths: A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/README.md A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/class/accessing/project.st A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/class/development support/DevelopmentSupport.st A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/class/development support/validate.st A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/class/loading/load.st A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/class/loading/loadBleedingEdge.st A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/class/loading/loadDevelopment.st A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/class/metacello tool support/isMetacelloConfig.st A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/class/private/baseConfigurationClassIfAbsent_.st A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/class/private/ensureMetacello.st A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/class/private/ensureMetacelloBaseConfiguration.st A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/definition.st A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/accessing/customProjectAttributes.st A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/accessing/project.st A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/baselines/baseline20_.st A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/symbolic versions/development_.st A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGTInspectorCore.package/ConfigurationOfGTInspectorCore.class/instance/versions/version200_.st A ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/README.md A ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/class/accessing/project.st A ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/class/development support/DevelopmentSupport.st A ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/class/development support/validate.st A ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/class/loading/load.st A ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/class/loading/loadBleedingEdge.st A ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/class/loading/loadDevelopment.st A ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/class/metacello tool support/isMetacelloConfig.st A ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/class/private/baseConfigurationClassIfAbsent_.st A ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/class/private/ensureMetacello.st A ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/class/private/ensureMetacelloBaseConfiguration.st A ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/definition.st A ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/accessing/customProjectAttributes.st A ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/accessing/project.st A ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/baselines/baseline20_.st A ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/symbolic versions/development_.st A ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/symbolic versions/stable_.st A ConfigurationOfGTPlaygroundCore.package/ConfigurationOfGTPlaygroundCore.class/instance/versions/version200_.st A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/README.md A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/class/accessing/project.st A ConfigurationOfGlamourCore.package/ConfigurationOfGlamourCore.class/class/development support/DevelopmentSupport.st A
[Pharo-dev] [pharo-project/pharo-core]
Branch: refs/tags/40360 Home: https://github.com/pharo-project/pharo-core
[Pharo-dev] StandardFileStreamopen:forWrite: serious isse...
Code (Transcript calls of mine)
open: fileName forWrite: writeMode
Open the file with the given name. If writeMode is true, allow writing,
otherwise open the file in read-only mode.
| f |
f := fileName asVmPathName.
Transcript log: 'File:', f.
fileID := StandardFileStream retryWithGC:[self primOpen: f writable:
writeMode]
until:[:id| id notNil]
forFileNamed: fileName.
fileID ifNil: [
' Cannot get fileID' logCr.
^ nil]. allows sender to detect failure
(' Got fileID: ', fileID printString) logCr.
name := fileName.
self register.
rwmode := writeMode.
buffer1 := String new: 1.
self enableReadBuffering
I have a ton of files to open. And some were slow to return a problem.
After digging, I got to the method above.
Now at one moment, I get nil fileIDs.
What is that retryWithGC: until: thing???
retryWithGC: execBlock until: testBlock forFileNamed: fullName
Re-implemented to only force GC if a file with the given name exists |
blockValue foundIt | blockValue := execBlock value. (testBlock value:
blockValue) ifTrue:[^blockValue]. See if we have a file with the given
name foundIt := self registry keys hold on strongly for now
anySatisfy:[:file| file name sameAs: fullName]. foundIt
ifFalse:[^blockValue]. Smalltalk garbageCollectMost. blockValue :=
execBlock value. (testBlock value: blockValue) ifTrue:[^blockValue].
Smalltalk garbageCollect. ^execBlock value.
Huh, yeah, some lookup going on in a registry...
and GCs? For file opens?
I am doing these opens in a webapp, what I want is to know if the file is
there or not and fail fast, not have all of this thing (debugging kind of
nightmarish...)
I have tested with 100 files and of course it all works since I get the IDs
back from the registry.
But at one point, it all fails. Registry full?
What to do here?
TIA
Phil
Re: [Pharo-dev] StandardFileStreamopen:forWrite: serious isse...
Yes, weird code ;-)
The registry seems unlimited, it is just a WeakRegistry.
I guess the GC is there to trigger weak reference cleanup.
On the other hand, there is always a limited on the number of open files at the
OS level.
The main thing is, if you use tons of (open) files, to always close them as
fast as possible, and to not let that happen automatically or lose them in the
case of exceptions.
On 07 Nov 2014, at 12:42, p...@highoctane.be wrote:
Code (Transcript calls of mine)
open: fileName forWrite: writeMode
Open the file with the given name. If writeMode is true, allow
writing, otherwise open the file in read-only mode.
| f |
f := fileName asVmPathName.
Transcript log: 'File:', f.
fileID := StandardFileStream retryWithGC:[self primOpen: f writable:
writeMode]
until:[:id| id notNil]
forFileNamed: fileName.
fileID ifNil: [
' Cannot get fileID' logCr.
^ nil]. allows sender to detect failure
(' Got fileID: ', fileID printString) logCr.
name := fileName.
self register.
rwmode := writeMode.
buffer1 := String new: 1.
self enableReadBuffering
I have a ton of files to open. And some were slow to return a problem.
After digging, I got to the method above.
Now at one moment, I get nil fileIDs.
What is that retryWithGC: until: thing???
retryWithGC: execBlock until: testBlock forFileNamed: fullName
Re-implemented to only force GC if a file with the given name exists
| blockValue foundIt |
blockValue := execBlock value.
(testBlock value: blockValue) ifTrue:[^blockValue].
See if we have a file with the given name
foundIt := self registry keys hold on strongly for now
anySatisfy:[:file| file name sameAs: fullName].
foundIt ifFalse:[^blockValue].
Smalltalk garbageCollectMost.
blockValue := execBlock value.
(testBlock value: blockValue) ifTrue:[^blockValue].
Smalltalk garbageCollect.
^execBlock value.
Huh, yeah, some lookup going on in a registry...
and GCs? For file opens?
I am doing these opens in a webapp, what I want is to know if the file is
there or not and fail fast, not have all of this thing (debugging kind of
nightmarish...)
I have tested with 100 files and of course it all works since I get the IDs
back from the registry.
But at one point, it all fails. Registry full?
What to do here?
TIA
Phil
Re: [Pharo-dev] StandardFileStreamopen:forWrite: serious isse...
Well, I am not keeping things open... (some local vars to get some easier
stepping)
measurementForTarget: aTargetId onSection: aSection at: aRegistryKey
| item fileRef |
item := 'ACQ_', aTargetId, '-', aSection, '_', aRegistryKey,'.txt'.
fileRef := self monitoringDirectory / item.
^ [ fileRef readStreamDo: [ :s | s next: Config maxFileCharsToRead ] ]
on: Error do: [ :ex |
self warn: ('Cannot measure for target {1} on section {2} and registry key
{3}' format: { aTargetId asString. aSection asString. aRegistryKey asString
}).
ex return: ''
]
It works for a couple files but at one point, it just doesn't open things.
Even if files are closed.
When reusing the same files over and over, it works (like readStreamDo: for
1 times, I get the contents back).
I've simplified the call to retryWithGC: ... to avoid the registry
completely:
retryWithGC: execBlock until: testBlock forFileNamed: fullName
Re-implemented to only force GC if a file with the given name exists
| blockValue |
blockValue := execBlock value.
(testBlock value: blockValue) ifTrue:[^blockValue].
^blockValue
But the symptom is the same.
Time to go into the filePlugin?
Phil
On Fri, Nov 7, 2014 at 12:59 PM, Sven Van Caekenberghe s...@stfx.eu wrote:
Yes, weird code ;-)
The registry seems unlimited, it is just a WeakRegistry.
I guess the GC is there to trigger weak reference cleanup.
On the other hand, there is always a limited on the number of open files
at the OS level.
The main thing is, if you use tons of (open) files, to always close them
as fast as possible, and to not let that happen automatically or lose them
in the case of exceptions.
On 07 Nov 2014, at 12:42, p...@highoctane.be wrote:
Code (Transcript calls of mine)
open: fileName forWrite: writeMode
Open the file with the given name. If writeMode is true, allow
writing, otherwise open the file in read-only mode.
| f |
f := fileName asVmPathName.
Transcript log: 'File:', f.
fileID := StandardFileStream retryWithGC:[self primOpen: f
writable: writeMode]
until:[:id| id notNil]
forFileNamed: fileName.
fileID ifNil: [
' Cannot get fileID' logCr.
^ nil]. allows sender to detect failure
(' Got fileID: ', fileID printString) logCr.
name := fileName.
self register.
rwmode := writeMode.
buffer1 := String new: 1.
self enableReadBuffering
I have a ton of files to open. And some were slow to return a problem.
After digging, I got to the method above.
Now at one moment, I get nil fileIDs.
What is that retryWithGC: until: thing???
retryWithGC: execBlock until: testBlock forFileNamed: fullName
Re-implemented to only force GC if a file with the given name
exists
| blockValue foundIt |
blockValue := execBlock value.
(testBlock value: blockValue) ifTrue:[^blockValue].
See if we have a file with the given name
foundIt := self registry keys hold on strongly for now
anySatisfy:[:file| file name sameAs: fullName].
foundIt ifFalse:[^blockValue].
Smalltalk garbageCollectMost.
blockValue := execBlock value.
(testBlock value: blockValue) ifTrue:[^blockValue].
Smalltalk garbageCollect.
^execBlock value.
Huh, yeah, some lookup going on in a registry...
and GCs? For file opens?
I am doing these opens in a webapp, what I want is to know if the file
is there or not and fail fast, not have all of this thing (debugging kind
of nightmarish...)
I have tested with 100 files and of course it all works since I get the
IDs back from the registry.
But at one point, it all fails. Registry full?
What to do here?
TIA
Phil
Re: [Pharo-dev] StandardFileStreamopen:forWrite: serious isse...
I've now set ulimit -n 3000 and things are working.
Sorry for the noise, but this GC thing is still weird.
Phil
On Fri, Nov 7, 2014 at 12:59 PM, Sven Van Caekenberghe s...@stfx.eu wrote:
Yes, weird code ;-)
The registry seems unlimited, it is just a WeakRegistry.
I guess the GC is there to trigger weak reference cleanup.
On the other hand, there is always a limited on the number of open files
at the OS level.
The main thing is, if you use tons of (open) files, to always close them
as fast as possible, and to not let that happen automatically or lose them
in the case of exceptions.
On 07 Nov 2014, at 12:42, p...@highoctane.be wrote:
Code (Transcript calls of mine)
open: fileName forWrite: writeMode
Open the file with the given name. If writeMode is true, allow
writing, otherwise open the file in read-only mode.
| f |
f := fileName asVmPathName.
Transcript log: 'File:', f.
fileID := StandardFileStream retryWithGC:[self primOpen: f
writable: writeMode]
until:[:id| id notNil]
forFileNamed: fileName.
fileID ifNil: [
' Cannot get fileID' logCr.
^ nil]. allows sender to detect failure
(' Got fileID: ', fileID printString) logCr.
name := fileName.
self register.
rwmode := writeMode.
buffer1 := String new: 1.
self enableReadBuffering
I have a ton of files to open. And some were slow to return a problem.
After digging, I got to the method above.
Now at one moment, I get nil fileIDs.
What is that retryWithGC: until: thing???
retryWithGC: execBlock until: testBlock forFileNamed: fullName
Re-implemented to only force GC if a file with the given name
exists
| blockValue foundIt |
blockValue := execBlock value.
(testBlock value: blockValue) ifTrue:[^blockValue].
See if we have a file with the given name
foundIt := self registry keys hold on strongly for now
anySatisfy:[:file| file name sameAs: fullName].
foundIt ifFalse:[^blockValue].
Smalltalk garbageCollectMost.
blockValue := execBlock value.
(testBlock value: blockValue) ifTrue:[^blockValue].
Smalltalk garbageCollect.
^execBlock value.
Huh, yeah, some lookup going on in a registry...
and GCs? For file opens?
I am doing these opens in a webapp, what I want is to know if the file
is there or not and fail fast, not have all of this thing (debugging kind
of nightmarish...)
I have tested with 100 files and of course it all works since I get the
IDs back from the registry.
But at one point, it all fails. Registry full?
What to do here?
TIA
Phil
Re: [Pharo-dev] StandardFileStreamopen:forWrite: serious isse...
On 07 Nov 2014, at 13:16, p...@highoctane.be wrote:
I've now set ulimit -n 3000 and things are working.
Sorry for the noise, but this GC thing is still weird.
That would mean that you keep 1000s of files open concurrently.
Anyway, I just wrote this as a test:
'/tmp/pharo-files-test/' asFileReference ensureCreateDirectory in: [ :base |
0 to: 99 do: [ :each |
base / each asString writeStreamDo: [ :out |
out print: each; crlf; each asWords; crlf ] ] ].
10 timesRepeat: [
| file |
file := 99 atRandom asString.
'/tmp/pharo-files-test/' asFileReference / file readStreamDo: [ :in |
self assert: (in upToEnd beginsWith: file) ] ]
And it worked fine.
Phil
On Fri, Nov 7, 2014 at 12:59 PM, Sven Van Caekenberghe s...@stfx.eu wrote:
Yes, weird code ;-)
The registry seems unlimited, it is just a WeakRegistry.
I guess the GC is there to trigger weak reference cleanup.
On the other hand, there is always a limited on the number of open files at
the OS level.
The main thing is, if you use tons of (open) files, to always close them as
fast as possible, and to not let that happen automatically or lose them in
the case of exceptions.
On 07 Nov 2014, at 12:42, p...@highoctane.be wrote:
Code (Transcript calls of mine)
open: fileName forWrite: writeMode
Open the file with the given name. If writeMode is true, allow
writing, otherwise open the file in read-only mode.
| f |
f := fileName asVmPathName.
Transcript log: 'File:', f.
fileID := StandardFileStream retryWithGC:[self primOpen: f writable:
writeMode]
until:[:id| id notNil]
forFileNamed: fileName.
fileID ifNil: [
' Cannot get fileID' logCr.
^ nil]. allows sender to detect failure
(' Got fileID: ', fileID printString) logCr.
name := fileName.
self register.
rwmode := writeMode.
buffer1 := String new: 1.
self enableReadBuffering
I have a ton of files to open. And some were slow to return a problem.
After digging, I got to the method above.
Now at one moment, I get nil fileIDs.
What is that retryWithGC: until: thing???
retryWithGC: execBlock until: testBlock forFileNamed: fullName
Re-implemented to only force GC if a file with the given name exists
| blockValue foundIt |
blockValue := execBlock value.
(testBlock value: blockValue) ifTrue:[^blockValue].
See if we have a file with the given name
foundIt := self registry keys hold on strongly for now
anySatisfy:[:file| file name sameAs: fullName].
foundIt ifFalse:[^blockValue].
Smalltalk garbageCollectMost.
blockValue := execBlock value.
(testBlock value: blockValue) ifTrue:[^blockValue].
Smalltalk garbageCollect.
^execBlock value.
Huh, yeah, some lookup going on in a registry...
and GCs? For file opens?
I am doing these opens in a webapp, what I want is to know if the file is
there or not and fail fast, not have all of this thing (debugging kind of
nightmarish...)
I have tested with 100 files and of course it all works since I get the IDs
back from the registry.
But at one point, it all fails. Registry full?
What to do here?
TIA
Phil
Re: [Pharo-dev] StandardFileStreamopen:forWrite: serious isse...
I did tests like that and they work ok.
I am still puzzled on why this happens in my code as only do these
readStreamDo: [] and nothing is in parallel.
I've been putting more caching in my own code but still, there is something
hiding.
Phil
On Fri, Nov 7, 2014 at 1:27 PM, Sven Van Caekenberghe s...@stfx.eu wrote:
On 07 Nov 2014, at 13:16, p...@highoctane.be wrote:
I've now set ulimit -n 3000 and things are working.
Sorry for the noise, but this GC thing is still weird.
That would mean that you keep 1000s of files open concurrently.
Anyway, I just wrote this as a test:
'/tmp/pharo-files-test/' asFileReference ensureCreateDirectory in: [ :base
|
0 to: 99 do: [ :each |
base / each asString writeStreamDo: [ :out |
out print: each; crlf; each asWords; crlf ] ] ].
10 timesRepeat: [
| file |
file := 99 atRandom asString.
'/tmp/pharo-files-test/' asFileReference / file readStreamDo: [
:in |
self assert: (in upToEnd beginsWith: file) ] ]
And it worked fine.
Phil
On Fri, Nov 7, 2014 at 12:59 PM, Sven Van Caekenberghe s...@stfx.eu
wrote:
Yes, weird code ;-)
The registry seems unlimited, it is just a WeakRegistry.
I guess the GC is there to trigger weak reference cleanup.
On the other hand, there is always a limited on the number of open files
at the OS level.
The main thing is, if you use tons of (open) files, to always close them
as fast as possible, and to not let that happen automatically or lose them
in the case of exceptions.
On 07 Nov 2014, at 12:42, p...@highoctane.be wrote:
Code (Transcript calls of mine)
open: fileName forWrite: writeMode
Open the file with the given name. If writeMode is true, allow
writing, otherwise open the file in read-only mode.
| f |
f := fileName asVmPathName.
Transcript log: 'File:', f.
fileID := StandardFileStream retryWithGC:[self primOpen: f
writable: writeMode]
until:[:id| id notNil]
forFileNamed: fileName.
fileID ifNil: [
' Cannot get fileID' logCr.
^ nil]. allows sender to detect failure
(' Got fileID: ', fileID printString) logCr.
name := fileName.
self register.
rwmode := writeMode.
buffer1 := String new: 1.
self enableReadBuffering
I have a ton of files to open. And some were slow to return a problem.
After digging, I got to the method above.
Now at one moment, I get nil fileIDs.
What is that retryWithGC: until: thing???
retryWithGC: execBlock until: testBlock forFileNamed: fullName
Re-implemented to only force GC if a file with the given name
exists
| blockValue foundIt |
blockValue := execBlock value.
(testBlock value: blockValue) ifTrue:[^blockValue].
See if we have a file with the given name
foundIt := self registry keys hold on strongly for now
anySatisfy:[:file| file name sameAs: fullName].
foundIt ifFalse:[^blockValue].
Smalltalk garbageCollectMost.
blockValue := execBlock value.
(testBlock value: blockValue) ifTrue:[^blockValue].
Smalltalk garbageCollect.
^execBlock value.
Huh, yeah, some lookup going on in a registry...
and GCs? For file opens?
I am doing these opens in a webapp, what I want is to know if the file
is there or not and fail fast, not have all of this thing (debugging kind
of nightmarish...)
I have tested with 100 files and of course it all works since I get
the IDs back from the registry.
But at one point, it all fails. Registry full?
What to do here?
TIA
Phil
Re: [Pharo-dev] StandardFileStreamopen:forWrite: serious isse...
On 07 Nov 2014, at 13:42, p...@highoctane.be wrote:
I did tests like that and they work ok.
I am still puzzled on why this happens in my code as only do these
readStreamDo: [] and nothing is in parallel.
I've been putting more caching in my own code but still, there is something
hiding.
Yes, I think so, happy hunting ;-)
You could try to hunt for instances and references when the error occurs.
Phil
On Fri, Nov 7, 2014 at 1:27 PM, Sven Van Caekenberghe s...@stfx.eu wrote:
On 07 Nov 2014, at 13:16, p...@highoctane.be wrote:
I've now set ulimit -n 3000 and things are working.
Sorry for the noise, but this GC thing is still weird.
That would mean that you keep 1000s of files open concurrently.
Anyway, I just wrote this as a test:
'/tmp/pharo-files-test/' asFileReference ensureCreateDirectory in: [ :base |
0 to: 99 do: [ :each |
base / each asString writeStreamDo: [ :out |
out print: each; crlf; each asWords; crlf ] ] ].
10 timesRepeat: [
| file |
file := 99 atRandom asString.
'/tmp/pharo-files-test/' asFileReference / file readStreamDo: [ :in |
self assert: (in upToEnd beginsWith: file) ] ]
And it worked fine.
Phil
On Fri, Nov 7, 2014 at 12:59 PM, Sven Van Caekenberghe s...@stfx.eu wrote:
Yes, weird code ;-)
The registry seems unlimited, it is just a WeakRegistry.
I guess the GC is there to trigger weak reference cleanup.
On the other hand, there is always a limited on the number of open files at
the OS level.
The main thing is, if you use tons of (open) files, to always close them as
fast as possible, and to not let that happen automatically or lose them in
the case of exceptions.
On 07 Nov 2014, at 12:42, p...@highoctane.be wrote:
Code (Transcript calls of mine)
open: fileName forWrite: writeMode
Open the file with the given name. If writeMode is true, allow
writing, otherwise open the file in read-only mode.
| f |
f := fileName asVmPathName.
Transcript log: 'File:', f.
fileID := StandardFileStream retryWithGC:[self primOpen: f
writable: writeMode]
until:[:id| id notNil]
forFileNamed: fileName.
fileID ifNil: [
' Cannot get fileID' logCr.
^ nil]. allows sender to detect failure
(' Got fileID: ', fileID printString) logCr.
name := fileName.
self register.
rwmode := writeMode.
buffer1 := String new: 1.
self enableReadBuffering
I have a ton of files to open. And some were slow to return a problem.
After digging, I got to the method above.
Now at one moment, I get nil fileIDs.
What is that retryWithGC: until: thing???
retryWithGC: execBlock until: testBlock forFileNamed: fullName
Re-implemented to only force GC if a file with the given name
exists
| blockValue foundIt |
blockValue := execBlock value.
(testBlock value: blockValue) ifTrue:[^blockValue].
See if we have a file with the given name
foundIt := self registry keys hold on strongly for now
anySatisfy:[:file| file name sameAs: fullName].
foundIt ifFalse:[^blockValue].
Smalltalk garbageCollectMost.
blockValue := execBlock value.
(testBlock value: blockValue) ifTrue:[^blockValue].
Smalltalk garbageCollect.
^execBlock value.
Huh, yeah, some lookup going on in a registry...
and GCs? For file opens?
I am doing these opens in a webapp, what I want is to know if the file is
there or not and fail fast, not have all of this thing (debugging kind of
nightmarish...)
I have tested with 100 files and of course it all works since I get the
IDs back from the registry.
But at one point, it all fails. Registry full?
What to do here?
TIA
Phil
[Pharo-dev] Should Nautilus use Rubric?
Hi! Is it worth to integrate Rubric into Nautilus? Or is there any reason not to do it? Thank you a lot! Juraj
Re: [Pharo-dev] Should Nautilus use Rubric?
Hi Juraj, Rubric is in the image because of GT but I guess GT will use TxText when it will be released as the default text editor. As a consequence, Rubric will be removed from the image. For the record, Rubric is the reimplementation of PluggableTextMorph. I consider it as an improvement over PluggableTextMorph but It uses the old text model. TxText is much more sexy :) So, I think it is not worth to integrate Rubric more. Cheers Alain On 7 nov. 2014, at 14:07, Juraj Kubelka juraj.kube...@gmail.com wrote: Hi! Is it worth to integrate Rubric into Nautilus? Or is there any reason not to do it? Thank you a lot! Juraj
Re: [Pharo-dev] Should Nautilus use Rubric?
What is TxModel? Is it something which replaces Rubric? Or is it something we need to be able to integrate Rubric into Nautilus? What is the relation between TxModel and Rubric? Thanks! Juraj On Nov 7, 2014, at 10:24 AM, Esteban Lorenzano esteba...@gmail.com wrote: I would say yes. we would like to have rubric everywhere we need a real editor :) (while waiting for the new TxModel, this is the “less pain path”, IMO) Esteban On 07 Nov 2014, at 14:07, Juraj Kubelka juraj.kube...@gmail.com wrote: Hi! Is it worth to integrate Rubric into Nautilus? Or is there any reason not to do it? Thank you a lot! Juraj
Re: [Pharo-dev] Should Nautilus use Rubric?
I think we should submit TxModel to the vaporware awards 2014 :) Norbert Am 07.11.2014 um 14:24 schrieb Esteban Lorenzano esteba...@gmail.com: I would say yes. we would like to have rubric everywhere we need a real editor :) (while waiting for the new TxModel, this is the “less pain path”, IMO) Esteban On 07 Nov 2014, at 14:07, Juraj Kubelka juraj.kube...@gmail.com wrote: Hi! Is it worth to integrate Rubric into Nautilus? Or is there any reason not to do it? Thank you a lot! Juraj
Re: [Pharo-dev] Should Nautilus use Rubric?
TxModel implements the text model of TxText. http://smalltalkhub.com/mc/sig/TxText/main There is no direct relation with Rubric. TxText is a completely fresh text model whereas Rubric is a kind of fork of PluggableTextMorph. TxText is implemented with Athens and not Rubric. Cheers Alain On 7 nov. 2014, at 14:29, Juraj Kubelka juraj.kube...@gmail.com wrote: What is TxModel? Is it something which replaces Rubric? Or is it something we need to be able to integrate Rubric into Nautilus? What is the relation between TxModel and Rubric? Thanks! Juraj On Nov 7, 2014, at 10:24 AM, Esteban Lorenzano esteba...@gmail.com wrote: I would say yes. we would like to have rubric everywhere we need a real editor :) (while waiting for the new TxModel, this is the “less pain path”, IMO) Esteban On 07 Nov 2014, at 14:07, Juraj Kubelka juraj.kube...@gmail.com wrote: Hi! Is it worth to integrate Rubric into Nautilus? Or is there any reason not to do it? Thank you a lot! Juraj
Re: [Pharo-dev] Should Nautilus use Rubric?
LOL :D I dont think Igor would appreciate that ;) On Fri, Nov 7, 2014 at 3:32 PM, Norbert Hartl norb...@hartl.name wrote: I think we should submit TxModel to the vaporware awards 2014 :) Norbert Am 07.11.2014 um 14:24 schrieb Esteban Lorenzano esteba...@gmail.com: I would say yes. we would like to have rubric everywhere we need a real editor :) (while waiting for the new TxModel, this is the “less pain path”, IMO) Esteban On 07 Nov 2014, at 14:07, Juraj Kubelka juraj.kube...@gmail.com wrote: Hi! Is it worth to integrate Rubric into Nautilus? Or is there any reason not to do it? Thank you a lot! Juraj
Re: [Pharo-dev] Should Nautilus use Rubric?
On 7 nov. 2014, at 14:32, Norbert Hartl norb...@hartl.name wrote: I think we should submit TxModel to the vaporware awards 2014 :) Hi Norbert, I really don't think so. Have a look. TxText is a real perl, I can't believe it will not be released. Cheers Alain Norbert Am 07.11.2014 um 14:24 schrieb Esteban Lorenzano esteba...@gmail.com: I would say yes. we would like to have rubric everywhere we need a real editor :) (while waiting for the new TxModel, this is the “less pain path”, IMO) Esteban On 07 Nov 2014, at 14:07, Juraj Kubelka juraj.kube...@gmail.com wrote: Hi! Is it worth to integrate Rubric into Nautilus? Or is there any reason not to do it? Thank you a lot! Juraj
Re: [Pharo-dev] Should Nautilus use Rubric?
Actually, I’m (finally) about to integrate it (an alpha version). it will be in the image next week :P Esteban On 07 Nov 2014, at 14:32, Norbert Hartl norb...@hartl.name wrote: I think we should submit TxModel to the vaporware awards 2014 :) Norbert Am 07.11.2014 um 14:24 schrieb Esteban Lorenzano esteba...@gmail.com: I would say yes. we would like to have rubric everywhere we need a real editor :) (while waiting for the new TxModel, this is the “less pain path”, IMO) Esteban On 07 Nov 2014, at 14:07, Juraj Kubelka juraj.kube...@gmail.com wrote: Hi! Is it worth to integrate Rubric into Nautilus? Or is there any reason not to do it? Thank you a lot! Juraj
Re: [Pharo-dev] Should Nautilus use Rubric?
I agree with Alain here. From what I see Igor invested a lot into this and I think it is just a problem of time once again to make it complete and usable. The demos and code in the repo are really promising! Or did I miss something? To answer the original question it would be interesting: 1. why is Rubric better than the old model 2. what are the main differences between the old, Rubric and the new (not only features but also regarding integration) 3. what is the current state of TxText, what is missing 4. how could the community help Thanks T. Gesendet: Freitag, 07. November 2014 um 14:47 Uhr Von: Alain Plantec alain.plan...@yahoo.com An: Pharo Development List pharo-dev@lists.pharo.org Betreff: Re: [Pharo-dev] Should Nautilus use Rubric? On 7 nov. 2014, at 14:32, Norbert Hartl norb...@hartl.name wrote: I think we should submit TxModel to the vaporware awards 2014 :) Hi Norbert, I really don't think so. Have a look. TxText is a real perl, I can't believe it will not be released. Cheers Alain Norbert Am 07.11.2014 um 14:24 schrieb Esteban Lorenzano esteba...@gmail.com: I would say yes. we would like to have rubric everywhere we need a real editor :) (while waiting for the new TxModel, this is the “less pain path”, IMO) Esteban On 07 Nov 2014, at 14:07, Juraj Kubelka juraj.kube...@gmail.com wrote: Hi! Is it worth to integrate Rubric into Nautilus? Or is there any reason not to do it? Thank you a lot! Juraj
[Pharo-dev] playground history
In the latest Pharo4 (at least), the history of the text written in the Playground has gone! There is a nice publish icon but no way to get the history. Do I miss something or was it really removed? The history is very useful and I would like to get it back. Thanks, Christophe. smime.p7s Description: S/MIME cryptographic signature
Re: [Pharo-dev] Should Nautilus use Rubric?
:)) On 7 nov. 2014, at 14:52, Esteban Lorenzano esteba...@gmail.com wrote: Actually, I’m (finally) about to integrate it (an alpha version). it will be in the image next week :P Esteban On 07 Nov 2014, at 14:32, Norbert Hartl norb...@hartl.name wrote: I think we should submit TxModel to the vaporware awards 2014 :) Norbert Am 07.11.2014 um 14:24 schrieb Esteban Lorenzano esteba...@gmail.com: I would say yes. we would like to have rubric everywhere we need a real editor :) (while waiting for the new TxModel, this is the “less pain path”, IMO) Esteban On 07 Nov 2014, at 14:07, Juraj Kubelka juraj.kube...@gmail.com wrote: Hi! Is it worth to integrate Rubric into Nautilus? Or is there any reason not to do it? Thank you a lot! Juraj
Re: [Pharo-dev] Should Nautilus use Rubric?
Hurrayy Good news! Thanks! Norbert Am 07.11.2014 um 14:52 schrieb Esteban Lorenzano esteba...@gmail.com: Actually, I’m (finally) about to integrate it (an alpha version). it will be in the image next week :P Esteban On 07 Nov 2014, at 14:32, Norbert Hartl norb...@hartl.name wrote: I think we should submit TxModel to the vaporware awards 2014 :) Norbert Am 07.11.2014 um 14:24 schrieb Esteban Lorenzano esteba...@gmail.com: I would say yes. we would like to have rubric everywhere we need a real editor :) (while waiting for the new TxModel, this is the “less pain path”, IMO) Esteban On 07 Nov 2014, at 14:07, Juraj Kubelka juraj.kube...@gmail.com wrote: Hi! Is it worth to integrate Rubric into Nautilus? Or is there any reason not to do it? Thank you a lot! Juraj
Re: [Pharo-dev] playground history
FYI: Andrei is away from his computer for a few days. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Nov 7, 2014, at 11:04 AM, Christophe Demarey christophe.dema...@inria.fr wrote: In the latest Pharo4 (at least), the history of the text written in the Playground has gone! There is a nice publish icon but no way to get the history. Do I miss something or was it really removed? The history is very useful and I would like to get it back. Thanks, Christophe.
[Pharo-dev] edit values in GTInspector
Hi, Is it planned to add the possibility to edit instances variables of an object directly from the inspector. I mean without evaluating code, just by clicking on the value and update it? Regards, Christophe. smime.p7s Description: S/MIME cryptographic signature
Re: [Pharo-dev] edit values in GTInspector
I already asked this too, so +1 - this is needed. On 07 Nov 2014, at 16:29, Christophe Demarey christophe.dema...@inria.fr wrote: Hi, Is it planned to add the possibility to edit instances variables of an object directly from the inspector. I mean without evaluating code, just by clicking on the value and update it? Regards, Christophe.
Re: [Pharo-dev] NAtiveBoost error
This is off topic. I tried to post it as a top level thread but I have become unknown. I don't know if you want this crap in here but I have decided not to wait for the postmaster to get back to me on the subject of becoming known. Feel free. ( Original-SUBJECT: ( picoVerse-:( what about state , is state really evil? ) ) ) I am a Smalltalker. But in the past few months i have been running with the Haskellers. The Haskellers hate state. This seemed strange at first because as a Smalltalker i love(d) state. State iswas my friend. 90% of my life as a Smalltalker is state wrangling. I am a state herder. The debugger is my staff I use to whack the state. And TestCase is my sheep dog. But to the Haskellers state is the evil trinity of satan the anti christ and the false prophet all rolled into one. State is the true dev incarnation of the total catastrophe of development Armageddon. Blood up to the bridles for hundreds of miles. Dogs and cats living together. Mass hysteria. They say. I'm not sure i quite get it yet but they keep preaching on this one point most of all. State is evil. You must keep all state in a Monad. As many methods/functions m as possible must be 100% dependent on the input parameters ONLY. No hidden instance variables affecting the return value of m are allowed. The only effect m can have is to return a value. If all this is true then m is pure. And pure is good. Pure is very good. And the wind says very. So i wonder if any of you fellow Smalltalkers have thought about this at all. Thanks Kjell E Godø (( Maybe Smalltalk should be called Statewalk as in yak it up fuzz ball. )) On Tuesday, November 4, 2014, Alain Rastoul alf.mmm@gmail.com wrote: Stef, As I said to Igor, the main problem about NativeBoost was between the chair and the keyboard... :) It is my first use of NativeBoost, I simply overlooked the very good existing chapter of EnterprisePharo on NativeBoost (NativeBoost recipes, the X11 journey) and misused the NativeBoost marshalling of data types. NAtiveBoost is great. If I achieve my experiments with zeromq and ends up with something clean (not the case actually, and not my first goal), I will be glad to add a chapter about that. My current problem is about a different socket behaviour between windows and linux. I think this is not a problem with ZeroMQ, the C program works as expected, I have to look for an explanation. No stress about that Alain Le 04/11/2014 10:39, stepharo a écrit : Alain which nativeboost chapter :)? Could you propose a paragraph so that we cover the problem you faced? Stef On 4/11/14 00:44, Alain Rastoul wrote: Hi Igor, Thank you for your answer, it worked perfectly Looks like I overlooked the nativeboost chapter .. 10 timesRepeatAfterMe: [self rtfm ] . And my suggestion about testing nil was stupid, much better to fail soon. ... I am an ass on this one... However, I am struggling on another point you already answered in the past in the mailing list to a guy who wanted to use socket.io : (http://forum.world.st/socket-io-td3891592.html#a3893031) Sockets in Pharo are not blocking the whole VM. What they block is the process which working with concrete socket. But other processes can still run, while one waiting data / even from single socket. on windows, zmq socket receive is blocking, on linux, not blocking (hence not working). As zmq is doing is IO on another thread, I guess there is some side effect of socket receive timeout settings somewhere (in the plugin ?) - just a guess... Getting socket options shows no difference, but I don't know how it is done on the vm side with regards to threads and if the socket is the same (zmq socket is not the tcp socket)... And on linux, the equivalent C program of to the smalltalk version blocks as expected. I a mperplexified ... may be I should look at vm and plugin code (VMMaker package IIRC) ? Do you have another advice ? Thanks you Alain Le 03/11/2014 02:12, Igor Stasenko a écrit : NBExternalArray instances cannot be passed directly to functions expecting pointers. use 'myarray address' for arguments. On 3 November 2014 00:20, Alain Rastoul alf.mmm@gmail.com mailto:alf.mmm@gmail.com wrote: Hi, I have a problem with a nativeboost call, but I don't see what I do wrong. library function prototype is: int zmq_getsockopt (void *socket, int option_name, void *option_value, size_t *option_len); my calling method in pharo is: zmq_getsockopt: socket option_name: option_name option_value: option_value option_len: option_len primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode ^self nbCall: #(int zmq_getsockopt (void *socket, int option_name, void * option_value, size_t* option_len) ) when I call it with ...
Re: [Pharo-dev] playground history
On 07 Nov 2014, at 15:04, Christophe Demarey christophe.dema...@inria.fr wrote: In the latest Pharo4 (at least), the history of the text written in the Playground has gone! There is a nice publish icon but no way to get the history. Do I miss something or was it really removed? The history is very useful and I would like to get it back. it appears when you open a new Playground. I added an issue: https://pharo.fogbugz.com/f/cases/14414/Playground-history-only-shown-after-opening-a-new-workspace https://pharo.fogbugz.com/f/cases/14414/Playground-history-only-shown-after-opening-a-new-workspace Marcus
Re: [Pharo-dev] NAtiveBoost error
please tell me where this could actually legitimately go. On Friday, November 7, 2014, Kjell Godo squeakl...@gmail.com wrote: This is off topic. I tried to post it as a top level thread but I have become unknown. I don't know if you want this crap in here but I have decided not to wait for the postmaster to get back to me on the subject of becoming known. Feel free. ( Original-SUBJECT: ( picoVerse-:( what about state , is state really evil? ) ) ) I am a Smalltalker. But in the past few months i have been running with the Haskellers. The Haskellers hate state. This seemed strange at first because as a Smalltalker i love(d) state. State iswas my friend. 90% of my life as a Smalltalker is state wrangling. I am a state herder. The debugger is my staff I use to whack the state. And TestCase is my sheep dog. But to the Haskellers state is the evil trinity of satan the anti christ and the false prophet all rolled into one. State is the true dev incarnation of the total catastrophe of development Armageddon. Blood up to the bridles for hundreds of miles. Dogs and cats living together. Mass hysteria. They say. I'm not sure i quite get it yet but they keep preaching on this one point most of all. State is evil. You must keep all state in a Monad. As many methods/functions m as possible must be 100% dependent on the input parameters ONLY. No hidden instance variables affecting the return value of m are allowed. The only effect m can have is to return a value. If all this is true then m is pure. And pure is good. Pure is very good. And the wind says very. So i wonder if any of you fellow Smalltalkers have thought about this at all. Thanks Kjell E Godø (( Maybe Smalltalk should be called Statewalk as in yak it up fuzz ball. )) On Tuesday, November 4, 2014, Alain Rastoul alf.mmm@gmail.com javascript:_e(%7B%7D,'cvml','alf.mmm@gmail.com'); wrote: Stef, As I said to Igor, the main problem about NativeBoost was between the chair and the keyboard... :) It is my first use of NativeBoost, I simply overlooked the very good existing chapter of EnterprisePharo on NativeBoost (NativeBoost recipes, the X11 journey) and misused the NativeBoost marshalling of data types. NAtiveBoost is great. If I achieve my experiments with zeromq and ends up with something clean (not the case actually, and not my first goal), I will be glad to add a chapter about that. My current problem is about a different socket behaviour between windows and linux. I think this is not a problem with ZeroMQ, the C program works as expected, I have to look for an explanation. No stress about that Alain Le 04/11/2014 10:39, stepharo a écrit : Alain which nativeboost chapter :)? Could you propose a paragraph so that we cover the problem you faced? Stef On 4/11/14 00:44, Alain Rastoul wrote: Hi Igor, Thank you for your answer, it worked perfectly Looks like I overlooked the nativeboost chapter .. 10 timesRepeatAfterMe: [self rtfm ] . And my suggestion about testing nil was stupid, much better to fail soon. ... I am an ass on this one... However, I am struggling on another point you already answered in the past in the mailing list to a guy who wanted to use socket.io : (http://forum.world.st/socket-io-td3891592.html#a3893031) Sockets in Pharo are not blocking the whole VM. What they block is the process which working with concrete socket. But other processes can still run, while one waiting data / even from single socket. on windows, zmq socket receive is blocking, on linux, not blocking (hence not working). As zmq is doing is IO on another thread, I guess there is some side effect of socket receive timeout settings somewhere (in the plugin ?) - just a guess... Getting socket options shows no difference, but I don't know how it is done on the vm side with regards to threads and if the socket is the same (zmq socket is not the tcp socket)... And on linux, the equivalent C program of to the smalltalk version blocks as expected. I a mperplexified ... may be I should look at vm and plugin code (VMMaker package IIRC) ? Do you have another advice ? Thanks you Alain Le 03/11/2014 02:12, Igor Stasenko a écrit : NBExternalArray instances cannot be passed directly to functions expecting pointers. use 'myarray address' for arguments. On 3 November 2014 00:20, Alain Rastoul alf.mmm@gmail.com mailto:alf.mmm@gmail.com wrote: Hi, I have a problem with a nativeboost call, but I don't see what I do wrong. library function prototype is: int zmq_getsockopt (void *socket, int option_name, void *option_value, size_t *option_len); my calling method in pharo is: zmq_getsockopt: socket option_name: option_name option_value: option_value option_len: option_len primitive:
Re: [Pharo-dev] playground history
+1 I also would like to have some other stuff from the older workspace menu: - make unclosable (I use it a lot, because time to time I start closing windows like a maniac… and of course, I do not see which one should stay open) - open/save as… - inspect variables - reset variables cheers, Esteban On 07 Nov 2014, at 15:04, Christophe Demarey christophe.dema...@inria.fr wrote: In the latest Pharo4 (at least), the history of the text written in the Playground has gone! There is a nice publish icon but no way to get the history. Do I miss something or was it really removed? The history is very useful and I would like to get it back. Thanks, Christophe.
Re: [Pharo-dev] NAtiveBoost error
Yes, in one sense, object oriented programming involves state and is the opposite of pure functional programming. Now, there are clean and less clean ways of doing object oriented design. But I too have a hard time accepting or understanding how a useful real world piece of software can be written without some form of state. Mathematical functions are easy, but once you have a number of closures over some captured and shared state, you basically have a object. Passing a world object into and returning it modified from pure functions becomes heavy too. The world is not black or white, but a complex form of grey. There are many good ideas in (pure) functional programming, you can use all of them in Smalltalk, if you want. On 07 Nov 2014, at 16:51, Kjell Godo squeakl...@gmail.com wrote: This is off topic. I tried to post it as a top level thread but I have become unknown. I don't know if you want this crap in here but I have decided not to wait for the postmaster to get back to me on the subject of becoming known. Feel free. ( Original-SUBJECT: ( picoVerse-:( what about state , is state really evil? ) ) ) I am a Smalltalker. But in the past few months i have been running with the Haskellers. The Haskellers hate state. This seemed strange at first because as a Smalltalker i love(d) state. State iswas my friend. 90% of my life as a Smalltalker is state wrangling. I am a state herder. The debugger is my staff I use to whack the state. And TestCase is my sheep dog. But to the Haskellers state is the evil trinity of satan the anti christ and the false prophet all rolled into one. State is the true dev incarnation of the total catastrophe of development Armageddon. Blood up to the bridles for hundreds of miles. Dogs and cats living together. Mass hysteria. They say. I'm not sure i quite get it yet but they keep preaching on this one point most of all. State is evil. You must keep all state in a Monad. As many methods/functions m as possible must be 100% dependent on the input parameters ONLY. No hidden instance variables affecting the return value of m are allowed. The only effect m can have is to return a value. If all this is true then m is pure. And pure is good. Pure is very good. And the wind says very. So i wonder if any of you fellow Smalltalkers have thought about this at all. Thanks Kjell E Godø (( Maybe Smalltalk should be called Statewalk as in yak it up fuzz ball. )) On Tuesday, November 4, 2014, Alain Rastoul alf.mmm@gmail.com wrote: Stef, As I said to Igor, the main problem about NativeBoost was between the chair and the keyboard... :) It is my first use of NativeBoost, I simply overlooked the very good existing chapter of EnterprisePharo on NativeBoost (NativeBoost recipes, the X11 journey) and misused the NativeBoost marshalling of data types. NAtiveBoost is great. If I achieve my experiments with zeromq and ends up with something clean (not the case actually, and not my first goal), I will be glad to add a chapter about that. My current problem is about a different socket behaviour between windows and linux. I think this is not a problem with ZeroMQ, the C program works as expected, I have to look for an explanation. No stress about that Alain Le 04/11/2014 10:39, stepharo a écrit : Alain which nativeboost chapter :)? Could you propose a paragraph so that we cover the problem you faced? Stef On 4/11/14 00:44, Alain Rastoul wrote: Hi Igor, Thank you for your answer, it worked perfectly Looks like I overlooked the nativeboost chapter .. 10 timesRepeatAfterMe: [self rtfm ] . And my suggestion about testing nil was stupid, much better to fail soon. ... I am an ass on this one... However, I am struggling on another point you already answered in the past in the mailing list to a guy who wanted to use socket.io : (http://forum.world.st/socket-io-td3891592.html#a3893031) Sockets in Pharo are not blocking the whole VM. What they block is the process which working with concrete socket. But other processes can still run, while one waiting data / even from single socket. on windows, zmq socket receive is blocking, on linux, not blocking (hence not working). As zmq is doing is IO on another thread, I guess there is some side effect of socket receive timeout settings somewhere (in the plugin ?) - just a guess... Getting socket options shows no difference, but I don't know how it is done on the vm side with regards to threads and if the socket is the same (zmq socket is not the tcp socket)... And on linux, the equivalent C program of to the smalltalk version blocks as expected. I a mperplexified ... may be I should look at vm and plugin code (VMMaker package IIRC) ? Do you have another advice ? Thanks you Alain
Re: [Pharo-dev] playground history
Hi, It is there only if you have a history. Why should this be an issue? Doru -- www.tudorgirba.com Every thing has its own flow On 07 Nov 2014, at 16:45, Marcus Denker marcus.den...@inria.fr wrote: On 07 Nov 2014, at 15:04, Christophe Demarey christophe.dema...@inria.fr wrote: In the latest Pharo4 (at least), the history of the text written in the Playground has gone! There is a nice publish icon but no way to get the history. Do I miss something or was it really removed? The history is very useful and I would like to get it back. it appears when you open a new Playground. I added an issue: https://pharo.fogbugz.com/f/cases/14414/Playground-history-only-shown-after-opening-a-new-workspace Marcus
Re: [Pharo-dev] NAtiveBoost error
Computing is not mathematical proof. It has to have side effect(s), else there will be no need to compute anything, if result is known beforehand. And who said that smalltalk is all about state? It is not. It is all about objects. 90% of my life as a Smalltalker is state wrangling. I am a state herder. The debugger is my staff I use to whack the state. it is fallacy.. you see only what object(s) wanna show you. if they would want to hide certain things (state) from your eyes, you won't even notice, nor will be able to retrieve it. Because you interacting with live objects, not with a dead state. -- Best regards, Igor Stasenko.
Re: [Pharo-dev] StandardFileStreamopen:forWrite: serious isse...
Hi Phil,
On Fri, Nov 7, 2014 at 3:42 AM, p...@highoctane.be p...@highoctane.be
wrote:
Code (Transcript calls of mine)
open: fileName forWrite: writeMode
Open the file with the given name. If writeMode is true, allow writing,
otherwise open the file in read-only mode.
| f |
f := fileName asVmPathName.
Transcript log: 'File:', f.
fileID := StandardFileStream retryWithGC:[self primOpen: f writable:
writeMode]
until:[:id| id notNil]
forFileNamed: fileName.
fileID ifNil: [
' Cannot get fileID' logCr.
^ nil]. allows sender to detect failure
(' Got fileID: ', fileID printString) logCr.
name := fileName.
self register.
rwmode := writeMode.
buffer1 := String new: 1.
self enableReadBuffering
I have a ton of files to open. And some were slow to return a problem.
After digging, I got to the method above.
Now at one moment, I get nil fileIDs.
What is that retryWithGC: until: thing???
retryWithGC: execBlock until: testBlock forFileNamed: fullName
Re-implemented to only force GC if a file with the given name exists |
blockValue foundIt | blockValue := execBlock value. (testBlock value:
blockValue) ifTrue:[^blockValue]. See if we have a file with the given
name foundIt := self registry keys hold on strongly for now
anySatisfy:[:file| file name sameAs: fullName]. foundIt
ifFalse:[^blockValue]. Smalltalk garbageCollectMost. blockValue :=
execBlock value. (testBlock value: blockValue) ifTrue:[^blockValue].
Smalltalk garbageCollect. ^execBlock value.
I think its horrible personally but it /should/ work. The idea is that
files shouldn't need to be closed explicitly; which is fine; we want to be
able to rely on finalization to close them eventually. Hence retryWithGC:
is called when an open fails, presumably because it failed because the
process is out of file handles, presumably because several
as-yet-unfinalized files have yet to be finalized. So running the GC
/should/ run finalization. One issue could be that there are bugs meaning
that finalization does /not/ happen. For example, Igor could take a look
and find out quickly whether that's the case. Another issue could be that
the finalization loop is at too low a priority, or has been terminated for
some reason.
But finalization can not be relied upon to be timely. A better solution is
to explicity close files where possible using a form such
as forceNewFileNamed:do: et al. Another solution is possible in Spur where
we can simplify the finalization by using ephemerons so there are no
proxies for files. But that's not relevant immediately.
Huh, yeah, some lookup going on in a registry...
and GCs? For file opens?
I am doing these opens in a webapp, what I want is to know if the file is
there or not and fail fast, not have all of this thing (debugging kind of
nightmarish...)
I have tested with 100 files and of course it all works since I get the
IDs back from the registry.
But at one point, it all fails. Registry full?
What to do here?
TIA
Phil
--
best,
Eliot
Re: [Pharo-dev] NAtiveBoost error
Hmm… to me this mail looks like it is written by a Bot ? e.g. in a mailing list everyone can start a top level thread. unknown users can not post at all. And I am the “postmaster” of this list and I have not gotten any requests at all... On 07 Nov 2014, at 16:51, Kjell Godo squeakl...@gmail.com wrote: This is off topic. I tried to post it as a top level thread but I have become unknown. I don't know if you want this crap in here but I have decided not to wait for the postmaster to get back to me on the subject of becoming known. Feel free. ( Original-SUBJECT: ( picoVerse-:( what about state , is state really evil? ) ) ) I am a Smalltalker. But in the past few months i have been running with the Haskellers. The Haskellers hate state. This seemed strange at first because as a Smalltalker i love(d) state. State iswas my friend. 90% of my life as a Smalltalker is state wrangling. I am a state herder. The debugger is my staff I use to whack the state. And TestCase is my sheep dog. But to the Haskellers state is the evil trinity of satan the anti christ and the false prophet all rolled into one. State is the true dev incarnation of the total catastrophe of development Armageddon. Blood up to the bridles for hundreds of miles. Dogs and cats living together. Mass hysteria. They say. I'm not sure i quite get it yet but they keep preaching on this one point most of all. State is evil. You must keep all state in a Monad. As many methods/functions m as possible must be 100% dependent on the input parameters ONLY. No hidden instance variables affecting the return value of m are allowed. The only effect m can have is to return a value. If all this is true then m is pure. And pure is good. Pure is very good. And the wind says very. So i wonder if any of you fellow Smalltalkers have thought about this at all. Thanks Kjell E Godø (( Maybe Smalltalk should be called Statewalk as in yak it up fuzz ball. )) On Tuesday, November 4, 2014, Alain Rastoul alf.mmm@gmail.com mailto:alf.mmm@gmail.com wrote: Stef, As I said to Igor, the main problem about NativeBoost was between the chair and the keyboard... :) It is my first use of NativeBoost, I simply overlooked the very good existing chapter of EnterprisePharo on NativeBoost (NativeBoost recipes, the X11 journey) and misused the NativeBoost marshalling of data types. NAtiveBoost is great. If I achieve my experiments with zeromq and ends up with something clean (not the case actually, and not my first goal), I will be glad to add a chapter about that. My current problem is about a different socket behaviour between windows and linux. I think this is not a problem with ZeroMQ, the C program works as expected, I have to look for an explanation. No stress about that Alain Le 04/11/2014 10:39, stepharo a écrit : Alain which nativeboost chapter :)? Could you propose a paragraph so that we cover the problem you faced? Stef On 4/11/14 00:44, Alain Rastoul wrote: Hi Igor, Thank you for your answer, it worked perfectly Looks like I overlooked the nativeboost chapter .. 10 timesRepeatAfterMe: [self rtfm ] . And my suggestion about testing nil was stupid, much better to fail soon. ... I am an ass on this one... However, I am struggling on another point you already answered in the past in the mailing list to a guy who wanted to use socket.io http://socket.io/ : (http://forum.world.st/socket-io-td3891592.html#a3893031 http://forum.world.st/socket-io-td3891592.html#a3893031) Sockets in Pharo are not blocking the whole VM. What they block is the process which working with concrete socket. But other processes can still run, while one waiting data / even from single socket. on windows, zmq socket receive is blocking, on linux, not blocking (hence not working). As zmq is doing is IO on another thread, I guess there is some side effect of socket receive timeout settings somewhere (in the plugin ?) - just a guess... Getting socket options shows no difference, but I don't know how it is done on the vm side with regards to threads and if the socket is the same (zmq socket is not the tcp socket)... And on linux, the equivalent C program of to the smalltalk version blocks as expected. I a mperplexified ... may be I should look at vm and plugin code (VMMaker package IIRC) ? Do you have another advice ? Thanks you Alain Le 03/11/2014 02:12, Igor Stasenko a écrit : NBExternalArray instances cannot be passed directly to functions expecting pointers. use 'myarray address' for arguments. On 3 November 2014 00:20, Alain Rastoul alf.mmm@gmail.com mailto:alf.mmm@gmail.com wrote: Hi, I have a problem with a nativeboost call, but I don't see what I do wrong.
Re: [Pharo-dev] edit values in GTInspector
This is strange, I do not remember to have use this when I was using the old inspector. I usually trust what the inspector tells me only having open one. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Nov 7, 2014, at 12:40 PM, Marcus Denker marcus.den...@inria.fr wrote: Yes, editing state and inspectors need to be updated so you see live how value are changing even when they are changed from somewhere else.
Re: [Pharo-dev] edit values in GTInspector
It simply has to be possible to edit values and to see live updates, there is no way around it - else the GT inspector looks at dead objects, bye bye live programming. I think it is not cool that this is being ignored. On 07 Nov 2014, at 19:24, Alexandre Bergel alexandre.ber...@me.com wrote: This is strange, I do not remember to have use this when I was using the old inspector. I usually trust what the inspector tells me only having open one. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Nov 7, 2014, at 12:40 PM, Marcus Denker marcus.den...@inria.fr wrote: Yes, editing state and inspectors need to be updated so you see live how value are changing even when they are changed from somewhere else.
Re: [Pharo-dev] edit values in GTInspector
The feature for editing values in place is already implemented, just for some reasons related to changing the styling in a text editor it was slower than we wanted it to be so it wasn't enabled yet. We'll add it soon. I'm away from my computer this week :) Cheers, Andrei On Fri, Nov 7, 2014 at 3:31 PM, Sven Van Caekenberghe s...@stfx.eu wrote: It simply has to be possible to edit values and to see live updates, there is no way around it - else the GT inspector looks at dead objects, bye bye live programming. I think it is not cool that this is being ignored. On 07 Nov 2014, at 19:24, Alexandre Bergel alexandre.ber...@me.com wrote: This is strange, I do not remember to have use this when I was using the old inspector. I usually trust what the inspector tells me only having open one. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Nov 7, 2014, at 12:40 PM, Marcus Denker marcus.den...@inria.fr wrote: Yes, editing state and inspectors need to be updated so you see live how value are changing even when they are changed from somewhere else.
Re: [Pharo-dev] fixing 'format on display' and 'format on accept'
I like the idea because I would like to have all the code reformatted. Stef On 4/11/14 18:09, Paul DeBruicker wrote: Hi - I'm going to get 'format on display' and 'format on accept' working in Nautilus. In Pharo 3 in the settings browser under 'code browsing' there is a 'pretty print' check box. As far as I can tell it doesn't affect code displaying at all in Nautilus. Is it OK to repurpose that checkbox as a control for 'format on display' and to also add a check box right there for 'format on accept' ? If not what would be better? Thanks Paul
Re: [Pharo-dev] edit values in GTInspector
Hi all, We worked on it and came out with a prototype version. It will be possible to enter edition mode double clicking on the value. The problem we are facing is performance issues with Rubric when changing text mode from plain text to smalltalk code for syntax highlighting, to assign to the variable a value of the expression's result. Thank you for your feedback. Cheers, Alex On Nov 7, 2014 7:31 PM, Sven Van Caekenberghe s...@stfx.eu wrote: It simply has to be possible to edit values and to see live updates, there is no way around it - else the GT inspector looks at dead objects, bye bye live programming. I think it is not cool that this is being ignored. On 07 Nov 2014, at 19:24, Alexandre Bergel alexandre.ber...@me.com wrote: This is strange, I do not remember to have use this when I was using the old inspector. I usually trust what the inspector tells me only having open one. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Nov 7, 2014, at 12:40 PM, Marcus Denker marcus.den...@inria.fr wrote: Yes, editing state and inspectors need to be updated so you see live how value are changing even when they are changed from somewhere else.
[Pharo-dev] Gofer loadDevelopment Bug?
The following, although seemingly equivalent, produce different results... #1: Gofer it smalltalkhubUser: 'SeanDeNigris' project: 'SeansPlayground'; configurationOf: 'LivingCode'; load. #ConfigurationOfLivingCode asClass project development load. VS. #2: Gofer it smalltalkhubUser: 'SeanDeNigris' project: 'SeansPlayground'; configurationOf: 'LivingCode'; loadDevelopment #1 correctly loads package dependencies which #2 fails to load. - Cheers, Sean -- View this message in context: http://forum.world.st/Gofer-loadDevelopment-Bug-tp4788987.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] NAtiveBoost error
yeah, big electron computation over the wire will tell open your chakras to monads or die :) Le 07/11/2014 19:03, Marcus Denker a écrit : Hmm… to me this mail looks like it is written by a Bot ? e.g. in a mailing list everyone can start a top level thread. unknown users can not post at all. And I am the “postmaster” of this list and I have not gotten any requests at all... On 07 Nov 2014, at 16:51, Kjell Godo squeakl...@gmail.com mailto:squeakl...@gmail.com wrote: This is off topic. I tried to post it as a top level thread but I have become unknown. I don't know if you want this crap in here but I have decided not to wait for the postmaster to get back to me on the subject of becoming known. Feel free. ( Original-SUBJECT: ( picoVerse-:( what about state , is state really evil? ) ) ) I am a Smalltalker. But in the past few months i have been running with the Haskellers. The Haskellers hate state. This seemed strange at first because as a Smalltalker i love(d) state. State iswas my friend. 90% of my life as a Smalltalker is state wrangling. I am a state herder. The debugger is my staff I use to whack the state. And TestCase is my sheep dog. But to the Haskellers state is the evil trinity of satan the anti christ and the false prophet all rolled into one. State is the true dev incarnation of the total catastrophe of development Armageddon. Blood up to the bridles for hundreds of miles. Dogs and cats living together. Mass hysteria. They say. I'm not sure i quite get it yet but they keep preaching on this one point most of all. State is evil. You must keep all state in a Monad. As many methods/functions m as possible must be 100% dependent on the input parameters ONLY. No hidden instance variables affecting the return value of m are allowed. The only effect m can have is to return a value. If all this is true then m is pure. And pure is good. Pure is very good. And the wind says very. So i wonder if any of you fellow Smalltalkers have thought about this at all. Thanks Kjell E Godø (( Maybe Smalltalk should be called Statewalk as in yak it up fuzz ball. )) On Tuesday, November 4, 2014, Alain Rastoul alf.mmm@gmail.com mailto:alf.mmm@gmail.com wrote: Stef, As I said to Igor, the main problem about NativeBoost was between the chair and the keyboard... :) It is my first use of NativeBoost, I simply overlooked the very good existing chapter of EnterprisePharo on NativeBoost (NativeBoost recipes, the X11 journey) and misused the NativeBoost marshalling of data types. NAtiveBoost is great. If I achieve my experiments with zeromq and ends up with something clean (not the case actually, and not my first goal), I will be glad to add a chapter about that. My current problem is about a different socket behaviour between windows and linux. I think this is not a problem with ZeroMQ, the C program works as expected, I have to look for an explanation. No stress about that Alain Le 04/11/2014 10:39, stepharo a écrit : Alain which nativeboost chapter :)? Could you propose a paragraph so that we cover the problem you faced? Stef On 4/11/14 00:44, Alain Rastoul wrote: Hi Igor, Thank you for your answer, it worked perfectly Looks like I overlooked the nativeboost chapter .. 10 timesRepeatAfterMe: [self rtfm ] . And my suggestion about testing nil was stupid, much better to fail soon. ... I am an ass on this one... However, I am struggling on another point you already answered in the past in the mailing list to a guy who wanted to use socket.io http://socket.io/ : (http://forum.world.st/socket-__io-td3891592.html#a3893031 http://forum.world.st/socket-io-td3891592.html#a3893031) Sockets in Pharo are not blocking the whole VM. What they block is the process which working with concrete socket. But other processes can still run, while one waiting data / even from single socket. on windows, zmq socket receive is blocking, on linux, not blocking (hence not working). As zmq is doing is IO on another thread, I guess there is some side effect of socket receive timeout settings somewhere (in the plugin ?) - just a guess... Getting socket options shows no difference, but I don't know how it is done on the vm side with regards to threads and if the socket is the same (zmq socket is not the tcp socket)... And on linux, the equivalent C program of to the smalltalk version
Re: [Pharo-dev] edit values in GTInspector
Hi Sven, Neither of these requests are being ignored (see the other two replies), but good things take time. We would be happy to get more contributors :). Doru -- www.tudorgirba.com Every thing has its own flow On 07 Nov 2014, at 19:31, Sven Van Caekenberghe s...@stfx.eu wrote: It simply has to be possible to edit values and to see live updates, there is no way around it - else the GT inspector looks at dead objects, bye bye live programming. I think it is not cool that this is being ignored. On 07 Nov 2014, at 19:24, Alexandre Bergel alexandre.ber...@me.com wrote: This is strange, I do not remember to have use this when I was using the old inspector. I usually trust what the inspector tells me only having open one. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Nov 7, 2014, at 12:40 PM, Marcus Denker marcus.den...@inria.fr wrote: Yes, editing state and inspectors need to be updated so you see live how value are changing even when they are changed from somewhere else.
Re: [Pharo-dev] Should Nautilus use Rubric?
Indeed. Really great! Doru -- www.tudorgirba.com Every thing has its own flow On 07 Nov 2014, at 18:23, Juraj Kubelka juraj.kube...@gmail.com wrote: This is the great news! Thanks! Juraj On Nov 7, 2014, at 10:52 AM, Esteban Lorenzano esteba...@gmail.com wrote: Actually, I’m (finally) about to integrate it (an alpha version). it will be in the image next week :P Esteban On 07 Nov 2014, at 14:32, Norbert Hartl norb...@hartl.name wrote: I think we should submit TxModel to the vaporware awards 2014 :) Norbert Am 07.11.2014 um 14:24 schrieb Esteban Lorenzano esteba...@gmail.com: I would say yes. we would like to have rubric everywhere we need a real editor :) (while waiting for the new TxModel, this is the “less pain path”, IMO) Esteban On 07 Nov 2014, at 14:07, Juraj Kubelka juraj.kube...@gmail.com wrote: Hi! Is it worth to integrate Rubric into Nautilus? Or is there any reason not to do it? Thank you a lot! Juraj
Re: [Pharo-dev] NAtiveBoost error
On 4/11/14 20:30, Alain Rastoul wrote: Stef, As I said to Igor, the main problem about NativeBoost was between the chair and the keyboard... :) It is my first use of NativeBoost, I simply overlooked the very good existing chapter of EnterprisePharo on NativeBoost (NativeBoost recipes, the X11 journey) and misused the NativeBoost marshalling of data types. NAtiveBoost is great. If I achieve my experiments with zeromq and ends up with something clean (not the case actually, and not my first goal), I will be glad to add a chapter about that. ok je le note ;) My current problem is about a different socket behaviour between windows and linux. I think this is not a problem with ZeroMQ, the C program works as expected, I have to look for an explanation. No stress about that Alain Le 04/11/2014 10:39, stepharo a écrit : Alain which nativeboost chapter :)? Could you propose a paragraph so that we cover the problem you faced? Stef On 4/11/14 00:44, Alain Rastoul wrote: Hi Igor, Thank you for your answer, it worked perfectly Looks like I overlooked the nativeboost chapter .. 10 timesRepeatAfterMe: [self rtfm ] . And my suggestion about testing nil was stupid, much better to fail soon. ... I am an ass on this one... However, I am struggling on another point you already answered in the past in the mailing list to a guy who wanted to use socket.io : (http://forum.world.st/socket-io-td3891592.html#a3893031) Sockets in Pharo are not blocking the whole VM. What they block is the process which working with concrete socket. But other processes can still run, while one waiting data / even from single socket. on windows, zmq socket receive is blocking, on linux, not blocking (hence not working). As zmq is doing is IO on another thread, I guess there is some side effect of socket receive timeout settings somewhere (in the plugin ?) - just a guess... Getting socket options shows no difference, but I don't know how it is done on the vm side with regards to threads and if the socket is the same (zmq socket is not the tcp socket)... And on linux, the equivalent C program of to the smalltalk version blocks as expected. I a mperplexified ... may be I should look at vm and plugin code (VMMaker package IIRC) ? Do you have another advice ? Thanks you Alain Le 03/11/2014 02:12, Igor Stasenko a écrit : NBExternalArray instances cannot be passed directly to functions expecting pointers. use 'myarray address' for arguments. On 3 November 2014 00:20, Alain Rastoul alf.mmm@gmail.com mailto:alf.mmm@gmail.com wrote: Hi, I have a problem with a nativeboost call, but I don't see what I do wrong. library function prototype is: int zmq_getsockopt (void *socket, int option_name, void *option_value, size_t *option_len); my calling method in pharo is: zmq_getsockopt: socket option_name: option_name option_value: option_value option_len: option_len primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode ^self nbCall: #(int zmq_getsockopt (void *socket, int option_name, void * option_value, size_t* option_len) ) when I call it with ... optionValue := (NBExternalArray ofType: 'int') externalNew: 1. optionLen := (NBExternalArray ofType: 'size_t' ) externalNew: 1. [ optionValue at: 1 put: 0 . optionLen at: 1 put: (NBExternalType sizeOf: 'int') . rc := self zmq_getsockopt: socket option_name: option_name option_value: optionValue option_len: optionLen . value := optionValue at: 1 . ] ensure: [ optionValue free. optionLen free ]. ... I allways get an exception: error during FFI call : nil After stepping in NBFFICallout generation, I found something strange, the code generation seems not to be called because lastError stays at nil ? handleFailureIn: aContext nativeCode: aBlock lastError := self getErrorFrom: aContext lastError: NativeBoost lastError. getErrorFrom: aContext lastError: errorCode ... checks pragmas etc getErrorFrom: aContext lastError: errorCode ... lastError := aContext tempAt: method numTemps. = lastError = nil ??? shouldn't be ErrNoNativeCodeInMethod ? install native code and retry the send lastError = ErrNoNativeCodeInMethod ifTrue: [ ^ self generateCode: aBlock andRetry: aContext ]. never gets called ... ok, we're out of options, signal an error here ^ self signalError: lastError Could it be because I use this image on windows and unix ? Or because I had an exception at prototype parsing the first time because I forgot a ; at the end of the prototype ? Is my prototype correct or is it the origin of the
Re: [Pharo-dev] Browse anObject?
:) we can rename browse into browseClass. On 6/11/14 00:07, Sean P. DeNigris wrote: Ben Coman wrote I thought… the least surprising would be... Object#browse self browseClass This was exactly what I was objecting to. How is #browse sent to anObject not surprising when you mean #browseClass (which already exists)? Saying that what else could browse mean in this context? looks at the issue from someone who is already an expert. The point is that it may mean nothing to a newbie, and rightly so because IMHO it /is/ meaningless. - Cheers, Sean -- View this message in context: http://forum.world.st/Browse-anObject-tp4788401p4788650.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Re: [Pharo-dev] NAtiveBoost error
Its definetly an interesting concept. I am curious to give it a try because it would take me outside my comfort zone and there is nothing more that I love than getting outside my comfort zone. But I blame Pharo and the Pharo people who dont let me to try another language, damn them DAMN THEM I SAY Side effects certainly can be a source of trouble but alas they are not the holy grail of trouble. Coding is a complex subject so introducing restrictions of purity will produce some side effects. OH YES PUN WAS INTENDED Its easy to dismiss such an approach however without trying it in practice with real projects. But then I do also recognise that mixing types can be a problem too at some point that does not convince me into going to static type language. I think for Pharo state is much less of a problem because Pharo has very powerful inspector , debuger and IDE to track down state. So its easy for a pharo developer to be aware of state compared to some developer using another language and not using an IDE at all. If state becomes too complex then its a sign to refactor code and make it simpler. I do think however with powerful IDEs you can get around this problem easily. So I cant say I am a big believer of Haskell. Also I real hate the terminology side effect ... sounds too. elitist to me. On Fri, Nov 7, 2014 at 5:51 PM, Kjell Godo squeakl...@gmail.com wrote: This is off topic. I tried to post it as a top level thread but I have become unknown. I don't know if you want this crap in here but I have decided not to wait for the postmaster to get back to me on the subject of becoming known. Feel free. ( Original-SUBJECT: ( picoVerse-:( what about state , is state really evil? ) ) ) I am a Smalltalker. But in the past few months i have been running with the Haskellers. The Haskellers hate state. This seemed strange at first because as a Smalltalker i love(d) state. State iswas my friend. 90% of my life as a Smalltalker is state wrangling. I am a state herder. The debugger is my staff I use to whack the state. And TestCase is my sheep dog. But to the Haskellers state is the evil trinity of satan the anti christ and the false prophet all rolled into one. State is the true dev incarnation of the total catastrophe of development Armageddon. Blood up to the bridles for hundreds of miles. Dogs and cats living together. Mass hysteria. They say. I'm not sure i quite get it yet but they keep preaching on this one point most of all. State is evil. You must keep all state in a Monad. As many methods/functions m as possible must be 100% dependent on the input parameters ONLY. No hidden instance variables affecting the return value of m are allowed. The only effect m can have is to return a value. If all this is true then m is pure. And pure is good. Pure is very good. And the wind says very. So i wonder if any of you fellow Smalltalkers have thought about this at all. Thanks Kjell E Godø (( Maybe Smalltalk should be called Statewalk as in yak it up fuzz ball. )) On Tuesday, November 4, 2014, Alain Rastoul alf.mmm@gmail.com wrote: Stef, As I said to Igor, the main problem about NativeBoost was between the chair and the keyboard... :) It is my first use of NativeBoost, I simply overlooked the very good existing chapter of EnterprisePharo on NativeBoost (NativeBoost recipes, the X11 journey) and misused the NativeBoost marshalling of data types. NAtiveBoost is great. If I achieve my experiments with zeromq and ends up with something clean (not the case actually, and not my first goal), I will be glad to add a chapter about that. My current problem is about a different socket behaviour between windows and linux. I think this is not a problem with ZeroMQ, the C program works as expected, I have to look for an explanation. No stress about that Alain Le 04/11/2014 10:39, stepharo a écrit : Alain which nativeboost chapter :)? Could you propose a paragraph so that we cover the problem you faced? Stef On 4/11/14 00:44, Alain Rastoul wrote: Hi Igor, Thank you for your answer, it worked perfectly Looks like I overlooked the nativeboost chapter .. 10 timesRepeatAfterMe: [self rtfm ] . And my suggestion about testing nil was stupid, much better to fail soon. ... I am an ass on this one... However, I am struggling on another point you already answered in the past in the mailing list to a guy who wanted to use socket.io : (http://forum.world.st/socket-io-td3891592.html#a3893031) Sockets in Pharo are not blocking the whole VM. What they block is the process which working with concrete socket. But other processes can still run, while one waiting data / even from single socket. on windows, zmq socket receive is blocking, on linux, not blocking (hence not working). As zmq is doing is IO on another thread, I guess there is some
Re: [Pharo-dev] edit values in GTInspector
On 07 Nov 2014, at 21:02, Tudor Girba tu...@tudorgirba.com wrote: Hi Sven, Neither of these requests are being ignored (see the other two replies), but good things take time. So the editing is coming, super. We would be happy to get more contributors :). So how are we going to make the inspectors really live ? The old inspectors had this busy loop (well part of the morph step protocol) for updating. I am sure I do not have to explain why we need this. Before, it was maybe not efficient (enough) and you said it would be too expensive for large computations. So what is the solution ? An opt-in or opt-out mechanism ? Per object, per presentation ? Doru -- www.tudorgirba.com Every thing has its own flow On 07 Nov 2014, at 19:31, Sven Van Caekenberghe s...@stfx.eu wrote: It simply has to be possible to edit values and to see live updates, there is no way around it - else the GT inspector looks at dead objects, bye bye live programming. I think it is not cool that this is being ignored. On 07 Nov 2014, at 19:24, Alexandre Bergel alexandre.ber...@me.com wrote: This is strange, I do not remember to have use this when I was using the old inspector. I usually trust what the inspector tells me only having open one. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. On Nov 7, 2014, at 12:40 PM, Marcus Denker marcus.den...@inria.fr wrote: Yes, editing state and inspectors need to be updated so you see live how value are changing even when they are changed from somewhere else.
Re: [Pharo-dev] NAtiveBoost error
Well, it looks like this thread have somewhat derailed :) My initial question was about a problem I now think (but have to confirm) is a vm system call signals side effects with socket polling in zeroMQ code (remember this is the vmdev mailing list not the smalltalk user list). I don't like zealots of any kind (object, relational, functional, religious ...), my pun was essentially a joke about trying to send a stateless electron :o) over a wire as a computation to someone's answer I suspect beeing a troll (plug a chakra socket here for a zealot effect). To me at some point, we have to go into some kind of materialization and state, (even with pivotal who have to stores it's code as bits I guess ?) and certainly no judgement of any kind about other realms or langages, I like new ideas , new langages, and new experiences. Of course, functional programming, monads, lambda calculus interests everybody here (me too), I also would like to try functional programming too but have a project I want to take at some interesting level first, and this is my priority. If the intent was not a troll, and he wants to discuss about smalltalk object oriented realm why doesn't he *please* start a new thread and lot of people would give him valuable answers (some did here) about the small*talk* spirit which is (IMHO) essentially about object perception and message sending (hence behaviour or functional) but certainly not only state Regards, Alain Le 07/11/2014 22:04, kilon alios a écrit : Its definetly an interesting concept. I am curious to give it a try because it would take me outside my comfort zone and there is nothing more that I love than getting outside my comfort zone. But I blame Pharo and the Pharo people who dont let me to try another language, damn them DAMN THEM I SAY Side effects certainly can be a source of trouble but alas they are not the holy grail of trouble. Coding is a complex subject so introducing restrictions of purity will produce some side effects. OH YES PUN WAS INTENDED Its easy to dismiss such an approach however without trying it in practice with real projects. But then I do also recognise that mixing types can be a problem too at some point that does not convince me into going to static type language. I think for Pharo state is much less of a problem because Pharo has very powerful inspector , debuger and IDE to track down state. So its easy for a pharo developer to be aware of state compared to some developer using another language and not using an IDE at all. If state becomes too complex then its a sign to refactor code and make it simpler. I do think however with powerful IDEs you can get around this problem easily. So I cant say I am a big believer of Haskell. Also I real hate the terminology side effect ... sounds too. elitist to me. On Fri, Nov 7, 2014 at 5:51 PM, Kjell Godo squeakl...@gmail.com mailto:squeakl...@gmail.com wrote: This is off topic. I tried to post it as a top level thread but I have become unknown. I don't know if you want this crap in here but I have decided not to wait for the postmaster to get back to me on the subject of becoming known. Feel free. ( Original-SUBJECT: ( picoVerse-:( what about state , is state really evil? ) ) ) I am a Smalltalker. But in the past few months i have been running with the Haskellers. The Haskellers hate state. This seemed strange at first because as a Smalltalker i love(d) state. State iswas my friend. 90% of my life as a Smalltalker is state wrangling. I am a state herder. The debugger is my staff I use to whack the state. And TestCase is my sheep dog. But to the Haskellers state is the evil trinity of satan the anti christ and the false prophet all rolled into one. State is the true dev incarnation of the total catastrophe of development Armageddon. Blood up to the bridles for hundreds of miles. Dogs and cats living together. Mass hysteria. They say. I'm not sure i quite get it yet but they keep preaching on this one point most of all. State is evil. You must keep all state in a Monad. As many methods/functions m as possible must be 100% dependent on the input parameters ONLY. No hidden instance variables affecting the return value of m are allowed. The only effect m can have is to return a value. If all this is true then m is pure. And pure is good. Pure is very good. And the wind says very. So i wonder if any of you fellow Smalltalkers have thought about this at all. Thanks Kjell E Godø (( Maybe Smalltalk should be called Statewalk as in yak it up fuzz ball. )) On Tuesday, November 4, 2014, Alain Rastoul alf.mmm@gmail.com mailto:alf.mmm@gmail.com wrote: Stef, As I said to
Re: [Pharo-dev] NAtiveBoost error
On Fri, Nov 7, 2014 at 2:06 PM, Alain Rastoul alf.mmm@gmail.com wrote: Well, it looks like this thread have somewhat derailed :) My initial question was about a problem I now think (but have to confirm) is a vm system call signals side effects with socket polling in zeroMQ code (remember this is the vmdev mailing list not the smalltalk user list). I don't like zealots of any kind (object, relational, functional, religious ...), my pun was essentially a joke about trying to send a stateless electron :o) over a wire as a computation to someone's answer I suspect beeing a troll (plug a chakra socket here for a zealot effect). But electrons are not stateless; they have spin and energy ;-) To me at some point, we have to go into some kind of materialization and state, (even with pivotal who have to stores it's code as bits I guess ?) and certainly no judgement of any kind about other realms or langages, I like new ideas , new langages, and new experiences. Of course, functional programming, monads, lambda calculus interests everybody here (me too), I also would like to try functional programming too but have a project I want to take at some interesting level first, and this is my priority. If the intent was not a troll, and he wants to discuss about smalltalk object oriented realm why doesn't he *please* start a new thread and lot of people would give him valuable answers (some did here) about the small*talk* spirit which is (IMHO) essentially about object perception and message sending (hence behaviour or functional) but certainly not only state Regards, Alain Le 07/11/2014 22:04, kilon alios a écrit : Its definetly an interesting concept. I am curious to give it a try because it would take me outside my comfort zone and there is nothing more that I love than getting outside my comfort zone. But I blame Pharo and the Pharo people who dont let me to try another language, damn them DAMN THEM I SAY Side effects certainly can be a source of trouble but alas they are not the holy grail of trouble. Coding is a complex subject so introducing restrictions of purity will produce some side effects. OH YES PUN WAS INTENDED Its easy to dismiss such an approach however without trying it in practice with real projects. But then I do also recognise that mixing types can be a problem too at some point that does not convince me into going to static type language. I think for Pharo state is much less of a problem because Pharo has very powerful inspector , debuger and IDE to track down state. So its easy for a pharo developer to be aware of state compared to some developer using another language and not using an IDE at all. If state becomes too complex then its a sign to refactor code and make it simpler. I do think however with powerful IDEs you can get around this problem easily. So I cant say I am a big believer of Haskell. Also I real hate the terminology side effect ... sounds too. elitist to me. On Fri, Nov 7, 2014 at 5:51 PM, Kjell Godo squeakl...@gmail.com mailto:squeakl...@gmail.com wrote: This is off topic. I tried to post it as a top level thread but I have become unknown. I don't know if you want this crap in here but I have decided not to wait for the postmaster to get back to me on the subject of becoming known. Feel free. ( Original-SUBJECT: ( picoVerse-:( what about state , is state really evil? ) ) ) I am a Smalltalker. But in the past few months i have been running with the Haskellers. The Haskellers hate state. This seemed strange at first because as a Smalltalker i love(d) state. State iswas my friend. 90% of my life as a Smalltalker is state wrangling. I am a state herder. The debugger is my staff I use to whack the state. And TestCase is my sheep dog. But to the Haskellers state is the evil trinity of satan the anti christ and the false prophet all rolled into one. State is the true dev incarnation of the total catastrophe of development Armageddon. Blood up to the bridles for hundreds of miles. Dogs and cats living together. Mass hysteria. They say. I'm not sure i quite get it yet but they keep preaching on this one point most of all. State is evil. You must keep all state in a Monad. As many methods/functions m as possible must be 100% dependent on the input parameters ONLY. No hidden instance variables affecting the return value of m are allowed. The only effect m can have is to return a value. If all this is true then m is pure. And pure is good. Pure is very good. And the wind says very. So i wonder if any of you fellow Smalltalkers have thought about this at all. Thanks Kjell E Godø (( Maybe
Re: [Pharo-dev] NAtiveBoost error
Le 07/11/2014 23:14, Eliot Miranda a écrit : On Fri, Nov 7, 2014 at 2:06 PM, Alain Rastoul alf.mmm@gmail.com mailto:alf.mmm@gmail.com wrote: Well, it looks like this thread have somewhat derailed :) My initial question was about a problem I now think (but have to confirm) is a vm system call signals side effects with socket polling in zeroMQ code (remember this is the vmdev mailing list not the smalltalk user list). I don't like zealots of any kind (object, relational, functional, religious ...), my pun was essentially a joke about trying to send a stateless electron :o) over a wire as a computation to someone's answer I suspect beeing a troll (plug a chakra socket here for a zealot effect). But electrons are not stateless; they have spin and energy ;-) that was the point (the :o) smiley) ...how far we go :) To me at some point, we have to go into some kind of materialization and state, (even with pivotal who have to stores it's code as bits I guess ?) and certainly no judgement of any kind about other realms or langages, I like new ideas , new langages, and new experiences. Of course, functional programming, monads, lambda calculus interests everybody here (me too), I also would like to try functional programming too but have a project I want to take at some interesting level first, and this is my priority. If the intent was not a troll, and he wants to discuss about smalltalk object oriented realm why doesn't he *please* start a new thread and lot of people would give him valuable answers (some did here) about the small*talk* spirit which is (IMHO) essentially about object perception and message sending (hence behaviour or functional) but certainly not only state Regards, Alain Le 07/11/2014 22:04, kilon alios a écrit : Its definetly an interesting concept. I am curious to give it a try because it would take me outside my comfort zone and there is nothing more that I love than getting outside my comfort zone. But I blame Pharo and the Pharo people who dont let me to try another language, damn them DAMN THEM I SAY Side effects certainly can be a source of trouble but alas they are not the holy grail of trouble. Coding is a complex subject so introducing restrictions of purity will produce some side effects. OH YES PUN WAS INTENDED Its easy to dismiss such an approach however without trying it in practice with real projects. But then I do also recognise that mixing types can be a problem too at some point that does not convince me into going to static type language. I think for Pharo state is much less of a problem because Pharo has very powerful inspector , debuger and IDE to track down state. So its easy for a pharo developer to be aware of state compared to some developer using another language and not using an IDE at all. If state becomes too complex then its a sign to refactor code and make it simpler. I do think however with powerful IDEs you can get around this problem easily. So I cant say I am a big believer of Haskell. Also I real hate the terminology side effect ... sounds too. elitist to me. On Fri, Nov 7, 2014 at 5:51 PM, Kjell Godo squeakl...@gmail.com mailto:squeakl...@gmail.com mailto:squeakl...@gmail.com mailto:squeakl...@gmail.com wrote: This is off topic. I tried to post it as a top level thread but I have become unknown. I don't know if you want this crap in here but I have decided not to wait for the postmaster to get back to me on the subject of becoming known. Feel free. ( Original-SUBJECT: ( picoVerse-:( what about state , is state really evil? ) ) ) I am a Smalltalker. But in the past few months i have been running with the Haskellers. The Haskellers hate state. This seemed strange at first because as a Smalltalker i love(d) state. State iswas my friend. 90% of my life as a Smalltalker is state wrangling. I am a state herder. The debugger is my staff I use to whack the state. And TestCase is my sheep dog. But to the Haskellers state is the evil trinity of satan the anti christ and the false prophet all rolled into one. State is the true dev incarnation of the total catastrophe of
Re: [Pharo-dev] NAtiveBoost error
Le 07/11/2014 21:11, stepharo a écrit : On 4/11/14 20:30, Alain Rastoul wrote: Stef, As I said to Igor, the main problem about NativeBoost was between the chair and the keyboard... :) It is my first use of NativeBoost, I simply overlooked the very good existing chapter of EnterprisePharo on NativeBoost (NativeBoost recipes, the X11 journey) and misused the NativeBoost marshalling of data types. NAtiveBoost is great. If I achieve my experiments with zeromq and ends up with something clean (not the case actually, and not my first goal), I will be glad to add a chapter about that. ok je le note ;) Avec plaisir :) But to be honest, I am very disappointed with zeroMQ library, not what I was expecting reading docs and books (some hype, not only sure but some), lots of asserts in code like unlikely(condition), return code tests not clear, looks very fragile, breakable and somewhat uncertain (and often crashed). In fact about the linux problem, I suspect (really not sure yet) a side effect with the pharo vm signals, that should not be the case for a library. Reading some posts and answers about python interfacing problems, I think ZeroMQ works well in a program that is designed to use it and only. It may work well with other systems, but not designed in that mindset (assertions in posts like : failing here must abort the program?!). Things that make me think that zeroMQ is probably not a reliable thing to use in Pharo. Plus the only answer I had on the mq list was my own answer (or comment) on debugging the library :( BTW, I have the websocket B plan for that (first tests make me think it could be a better plan for my needs). It will be a different animal, but interesting too. My current problem is about a different socket behaviour between windows and linux. I think this is not a problem with ZeroMQ, the C program works as expected, I have to look for an explanation. No stress about that Alain Le 04/11/2014 10:39, stepharo a écrit : Alain which nativeboost chapter :)? Could you propose a paragraph so that we cover the problem you faced? Stef On 4/11/14 00:44, Alain Rastoul wrote: Hi Igor, Thank you for your answer, it worked perfectly Looks like I overlooked the nativeboost chapter .. 10 timesRepeatAfterMe: [self rtfm ] . And my suggestion about testing nil was stupid, much better to fail soon. ... I am an ass on this one... However, I am struggling on another point you already answered in the past in the mailing list to a guy who wanted to use socket.io : (http://forum.world.st/socket-io-td3891592.html#a3893031) Sockets in Pharo are not blocking the whole VM. What they block is the process which working with concrete socket. But other processes can still run, while one waiting data / even from single socket. on windows, zmq socket receive is blocking, on linux, not blocking (hence not working). As zmq is doing is IO on another thread, I guess there is some side effect of socket receive timeout settings somewhere (in the plugin ?) - just a guess... Getting socket options shows no difference, but I don't know how it is done on the vm side with regards to threads and if the socket is the same (zmq socket is not the tcp socket)... And on linux, the equivalent C program of to the smalltalk version blocks as expected. I a mperplexified ... may be I should look at vm and plugin code (VMMaker package IIRC) ? Do you have another advice ? Thanks you Alain Le 03/11/2014 02:12, Igor Stasenko a écrit : NBExternalArray instances cannot be passed directly to functions expecting pointers. use 'myarray address' for arguments. On 3 November 2014 00:20, Alain Rastoul alf.mmm@gmail.com mailto:alf.mmm@gmail.com wrote: Hi, I have a problem with a nativeboost call, but I don't see what I do wrong. library function prototype is: int zmq_getsockopt (void *socket, int option_name, void *option_value, size_t *option_len); my calling method in pharo is: zmq_getsockopt: socket option_name: option_name option_value: option_value option_len: option_len primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode ^self nbCall: #(int zmq_getsockopt (void *socket, int option_name, void * option_value, size_t* option_len) ) when I call it with ... optionValue := (NBExternalArray ofType: 'int') externalNew: 1. optionLen := (NBExternalArray ofType: 'size_t' ) externalNew: 1. [ optionValue at: 1 put: 0 . optionLen at: 1 put: (NBExternalType sizeOf: 'int') . rc := self zmq_getsockopt: socket option_name: option_name option_value: optionValue option_len: optionLen . value := optionValue at: 1 . ] ensure: [ optionValue free. optionLen free ]. ... I allways get an exception: error during FFI call : nil After stepping in NBFFICallout
Re: [Pharo-dev] inria survey
stepharo wrote: Hi guys you can help us to improve our communication as a research center. Please take some minutes to fill this little survey. Stef -- VERSION FRANÇAISE -- Créé depuis 2002 à Lille, le centre de recherche Inria Lille - Nord Europe souhaite faire un point d’étape sur sa notoriété et s’interroge sur l’image qu’il véhicule auprès des différents publics avec lesquels il collabore. Industriels, partenaires académiques, collectivités, chercheurs, journalistes, fournisseurs, étudiants, lycéens… Nous voulons savoir si vous nous connaissez bien et si vous auriez envie d’en savoir plus. Vos avis nous intéressent alors n’hésitez pas à compléter le questionnaire avant le 28 novembre. David Simplot-Ryl directeur Inria Lille - Nord Europe En pratique ; Lien vers le questionnaire : https://sondages.inria.fr/index.php/632788?lang=fr Clôture de l’enquête le 28 novembre. Temps de réponse au questionnaire : moins de 10min. Les résultats de l’enquête seront communiqués en 2015. http://www.inria.fr/centre/lille/actualites/enquete-sur-l-image-du-centre-inria-lille-nord-europe ENGLISH VERSION Created since 2002 in Lille, the Inria Lille - Nord Europe research center wish to make a report on its reputation and its image. Industrial and academic partners, researchers, journalists , suppliers, students,... We want to know if you know us well and if you would like to learn more. We are interested in your opinion then do not hesitate to complete the questionnaire before 28 November. David Simplot- Ryl director Inria Lille - Nord Europe David Simplot-Ryl director Inria Lille - Nord Europe In practice ; Link to the survey :https://sondages.inria.fr/index.php/632788?lang=fr (select English) Deadline to respond 28 November. Questionnaire response time : less than 10 minutes. The results of the survey will be released in 2015. http://www.inria.fr/en/centre/lille/news/inria-lille-nord-europe-survey I've completed it, but some ambiguities I encountered... What is Vulgarization of science ? For Patient specific model is this specifically referring to a medical application, or a translation error meaning User specific model? btw, it would have been nice to be able to go back to previous pages. cheers -ben
[Pharo-dev] Visit/accept method naming philosophy
This is a general query and something I've wondered several times before in different situations, but I use OSWindow as an example since that is what I happen to be looking at this time. For curiosity I was having a poke around OSWindow and seeing OSWindowMorphicEventHandlerhandleEvent: morphicEvent := anEvent accept: self. I wanted to view the code that could invoke, so I used cmd-M on #accept: to get the implementors, which lists 116 items, many of which are unrelated. Now its not t hard to guess which implementations are related, but it would be nicer to guess less. Would it be a reasonable philosophy to distinguish each package's #accept: method by appending the expect object type, like this... ? OSWindowMorphicEventHandlerhandleEvent: morphicEvent := anEvent acceptOSEventHandler: self. IRVisitorvisitNode: elem ^ elem acceptIRVisitor: self ParseNodeVisitorvisitBlockNode: aBlockNode aBlockNode statements do: [:statement | statement acceptParseNode: self] Or does such a convention constrain too much how you can extend a visitor pattern? cheers -ben
Re: [Pharo-dev] inria survey
I've completed it, but some ambiguities I encountered... What is Vulgarization of science” French people think it is the english translation of the french word vulgarisation scientifique http://fr.wikipedia.org/wiki/Vulgarisation It seems to be in the english dictionary as “to make popular”: http://dictionary.reverso.net/english-definition/vulgarisation (coming from latin I guess lots of languages have it with kind-of-the same meaning.) For my german ear it sound horrible, as “vulgär” has picked up *very* negative connotations. You really do not want to be that… or make your research that: http://www.dict.cc/deutsch-englisch/vulgär.html Marcus
Re: [Pharo-dev] edit values in GTInspector
On 07 Nov 2014, at 19:24, Alexandre Bergel alexandre.ber...@me.com wrote: This is strange, I do not remember to have use this when I was using the old inspector. I usually trust what the inspector tells me only having open one. But that’s the point: if the value changes, the inspector shows the old one. So you can *not* trust it. (and all the cool demos do not work anymore: adding an ivar to a class and the inspector on the object shows it, inspecting the world and showing how the mouse course position changes…) Marcus
Re: [Pharo-dev] Visit/accept method naming philosophy
Hi Ben, 2014-11-08 7:28 GMT+01:00 Ben Coman b...@openinworld.com: This is a general query and something I've wondered several times before in different situations, but I use OSWindow as an example since that is what I happen to be looking at this time. For curiosity I was having a poke around OSWindow and seeing OSWindowMorphicEventHandlerhandleEvent: morphicEvent := anEvent accept: self. I wanted to view the code that could invoke, so I used cmd-M on #accept: to get the implementors, which lists 116 items, many of which are unrelated. Now its not t hard to guess which implementations are related, but it would be nicer to guess less. Would it be a reasonable philosophy to distinguish each package's #accept: method by appending the expect object type, like this... ? OSWindowMorphicEventHandlerhandleEvent: morphicEvent := anEvent acceptOSEventHandler: self. IRVisitorvisitNode: elem ^ elem acceptIRVisitor: self ParseNodeVisitorvisitBlockNode: aBlockNode aBlockNode statements do: [:statement | statement acceptParseNode: self] Or does such a convention constrain too much how you can extend a visitor pattern? It has a nice a type is documentation for the programmer effect, so I'd say it could work. It would be interesting to see what it looks like on an external package of a certain size and with users. At the same time, your issue is also with the fact that filtering the relevant #accept: implementors could be easier, and this is a GUI issue for which we already have propositions (or we can think of some). Thierry cheers -ben
Re: [Pharo-dev] inria survey
2014-11-08 7:32 GMT+01:00 Marcus Denker marcus.den...@inria.fr: I've completed it, but some ambiguities I encountered... What is Vulgarization of science French people think it is the english translation of the french word vulgarisation scientifique http://fr.wikipedia.org/wiki/Vulgarisation It seems to be in the english dictionary as to make popular: http://dictionary.reverso.net/english-definition/vulgarisation (coming from latin I guess lots of languages have it with kind-of-the same meaning.) For my german ear it sound horrible, as vulgär has picked up *very* negative connotations. You really do not want to be that... or make your research that: http://www.dict.cc/deutsch-englisch/vulgär.html Knowing that vulgaire in french has more or less the same meaning than vulgär in German :) Thierry Marcus
Re: [Pharo-dev] edit values in GTInspector
What Alex was saying is that he only trusts an inspector that he just opened. This is clearly not ideal. Is there a way to get reliably notified when an object changes its state? Cheers, Doru On Sat, Nov 8, 2014 at 7:37 AM, Marcus Denker marcus.den...@inria.fr wrote: On 07 Nov 2014, at 19:24, Alexandre Bergel alexandre.ber...@me.com wrote: This is strange, I do not remember to have use this when I was using the old inspector. I usually trust what the inspector tells me only having open one. But that’s the point: if the value changes, the inspector shows the old one. So you can *not* trust it. (and all the cool demos do not work anymore: adding an ivar to a class and the inspector on the object shows it, inspecting the world and showing how the mouse course position changes…) Marcus -- www.tudorgirba.com Every thing has its own flow
