November 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Dealing with very large files

by stepharo

Alex there is a difference between reaing 1Gb 10 kbyte by 10 kByte and loading in memory 1 Gb. Stef On 4/11/14 14:51, Alexandre Bergel wrote: >> Is it enough to open a stream and traverse the stream? > > Yes. Pharo works well in that setting? > > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On Nov 4, 2014, at 10:24 AM, Tudor Girba <tudor(a)tudorgirba.com >> <mailto:tudor@tudorgirba.com>> wrote: >> >> Hi Alex, >> >> What is the scenario exacty? What do you mean by navigate? Is it >> enough to open a stream and traverse the stream? >> >> Doru >> >> On Tue, Nov 4, 2014 at 2:19 PM, Nicolai Hess <nicolaihess(a)web.de >> <mailto:nicolaihess@web.de>> wrote: >> >> 2014-11-04 13:59 GMT+01:00 Alexandre Bergel >> <alexandre.bergel(a)me.com <mailto:alexandre.bergel@me.com>>: >> >> Hi! >> >> A question just popped up: Can Pharo handle very large files? >> I mean, can I open and navigate within a 1 Gb file? >> Someone has experience to share? >> >> Cheers, >> Alexandre >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> 1GB works larger than 2GB does not work on linux yet: >> 14250 <https://pharo.fogbugz.com/default.asp?14250> >> Enable large file support on linux >> >> >> >> >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com/> >> >> "Every thing has its own flow" >

Nov. 7, 2014

Re: [Pharo-dev] edit values in GTInspector

by Sven Van Caekenberghe

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.bergel(a)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.denker(a)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. >

Nov. 7, 2014

Re: [Pharo-dev] edit values in GTInspector

by Alexandre Bergel

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.denker(a)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.

Nov. 7, 2014

Re: [Pharo-dev] playground history

by Marcus Denker

> On 07 Nov 2014, at 17:51, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > It is there only if you have a history. Why should this be an issue? > Because I was looking for it, there was even a file on disk, yet no way to get to it. Marcus

Nov. 7, 2014

Re: [Pharo-dev] NAtiveBoost error

by Marcus Denker

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 <squeaklist(a)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.cat(a)gmail.com <mailto:alf.mmm.cat@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.cat(a)gmail.com <> > <mailto:alf.mmm.cat@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 error ? > Is there a way to reset the lastError (aContext tempAt: method > numTemps) ? > I will try to reset it in debugger but may be there is a cleaner > way ? > would it be ok to change the test in handleFailure to > (lastError = ErrNoNativeCodeInMethod) or:[ lastError isNil ] ? > (I can open a bug in this case ) > > Any idea or comment is welcome > Thanks in advance > > Alain > > > > > > -- > Best regards, > Igor Stasenko. > > > > > > > > > >

Nov. 7, 2014

Re: [Pharo-dev] StandardFileStream>>open:forWrite: serious isse...

by Eliot Miranda

Hi Phil, On Fri, Nov 7, 2014 at 3:42 AM, phil(a)highoctane.be <phil(a)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. Huhhhhh, 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

Nov. 7, 2014

Re: [Pharo-dev] NAtiveBoost error

by Sven Van Caekenberghe

> On 07 Nov 2014, at 17:31, Kjell Godo <squeaklist(a)gmail.com> wrote: > > > > On Friday, November 7, 2014, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > 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. > > Why do you say heavy. Like you said, what they do is pass state as a parameter and return a modified state, often a copy with modifications added. In the real world, this state parameter will quickly become quite complex. How is handling and tediously passing around such a thing better ? And how is it different than referring to self ? My opinion is that you can write beautiful object code with clear abstractions, hiding implementation details behind nice APIs. But it is equally possible to write spaghetti code. It is up to you. > Are you talking about Haskell things that would be hard in Smalltalk? > > Or basic things that are hard in Haskell? > > When you say heavy do you mean slow or big? Smalltalk or Haskell. > > Usually the Haskellers talk about putting small pieces of data into a Monad > > and then working on it in there. using bind and return. > > Everything outside of the Monad is pure. or something. not sure. > > I'm not sure if the data inside of the Monad is acted upon by pure functions. > > I'm not quite sure why sticking state into a Monad unstateifies it. > > Why do Monads make state safe. > > Can Smalltalk have a Monad system? Should it? > > > 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 <squeaklist(a)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.cat(a)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.cat(a)gmail.com > > <mailto:alf.mmm.cat@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 error ? > > Is there a way to reset the lastError (aContext tempAt: method > > numTemps) ? > > I will try to reset it in debugger but may be there is a cleaner > > way ? > > would it be ok to change the test in handleFailure to > > (lastError = ErrNoNativeCodeInMethod) or:[ lastError isNil ] ? > > (I can open a bug in this case ) > > > > Any idea or comment is welcome > > Thanks in advance > > > > Alain > > > > > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > > > > > > > > > > > > > > > > >

Nov. 7, 2014

Re: [Pharo-dev] Should Nautilus use Rubric?

by Juraj Kubelka

This is the great news! Thanks! Juraj > On Nov 7, 2014, at 10:52 AM, Esteban Lorenzano <estebanlm(a)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 <norbert(a)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 <estebanlm(a)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.kubelka(a)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 >>> >>> >> >> > >

Nov. 7, 2014

Re: [Pharo-dev] Should Nautilus use Rubric?

by Sean P. DeNigris

EstebanLM wrote > it will be in the image next week :P Yiiiiiiiiiiipppppppppie!!!!! ----- Cheers, Sean -- View this message in context: http://forum.world.st/Should-Nautilus-use-Rubric-tp4788902p4788962.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Nov. 7, 2014

Re: [Pharo-dev] NAtiveBoost error

by Igor Stasenko

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.

Nov. 7, 2014