Re: [Pharo-dev] You can cheat in FFI as long as you don't get caught...
On 9 November 2017 at 16:28, Nicolas Cellier < nicolas.cellier.aka.n...@gmail.com> wrote: > > > 2017-11-09 12:24 GMT+01:00 Igor Stasenko <siguc...@gmail.com>: > >> >> On 9 November 2017 at 12:03, Esteban Lorenzano <esteba...@gmail.com> >> wrote: >> >>> yeah, but this is because LGitDiff, LGitRepository and LGitTree (and >>> many others) are defined as FFIExternalObjects while they should be >>> FFIOpaqueObjects. Then, the problem is that external objects are *already* >>> pointers (they have arity 1). >>> >>> >> hmm but the external objects were already designed with thought that it >> holding some opaque handle to some external object. it does not neccessary >> should be a pointer .. it could be some handle, >> that doesn't points directly to some memory location (like in windows api >> etc). >> they only difference is only in what function(s) expecting, e.g. if it >> takes a handle value - you should pass it by value (the handle itself), and >> when it asks for pointer to the handle (to fill a return value , for >> instance) - you passing a pointer to it. >> >> >> > > Agree that should not make a difference, a handle can be anything, a > pointer, an int, ... > > Technically, the git_tree are not opaque, they are struct. > BUT we don't care at all of their layout/fields from within Pharo and want > to treat them as Opaque. > - First reason: declaring fields would make the Pharo code fragile versus > future evolution of libgit2 because any change in the layout would create a > dangerous mismatch. > - Second reason: we never have to allocate space for those struct, the > library cares for us. > - Third reason: libgit2 APi will never deal with a git_tree, only > git_tree* or git_tree** > > So I think that you made a good choice to use a sort-of-handle (git_tree*). > Not me. I have nothing to do with libgit bindings.. But usually, for any who knows C it should be quite simple to follow a pattern.. it is like typedef foo_bar* FooBarObject; so, then you use FooBarObject instead of foo_bar* everywhere. I am now certain that it was the exact intention of FFIExternalObject > > Maybe we could rename superclass to FFIExternalObjectPointer to make > explicit that it adds a pointer arity? > We must also provide examples in class comment (or link to a Help page...) > > IIRC, FFIExternalObject intentionally was not allowing arity more than one. So, you can use it for passing it as a return-value argument to function, but you should not use it where function expecting an array/list of pointers of given type. Example: I have an external object bar from library foo (a foo_bar). > > C signature: void foo_create_bar(foo_bar **bar); > FFIExternalObjectPointer subclass: FooBar. > > a Smalltalk FooBar now represents a pointer to a foo_bar (a foo_bar *). > And the library will be invoked with: > > self call: #(void foo_create_bar(FooBar *self)) > > If the library function return a pointer to a foo_bar > > yes, if it using argument as a return-value. > C signature: foo_bar *foo_bar_alloc(size_t size); > > then we interface it like that: > > handle pointerAt: 1 put: (self call: #(FooBar foo_bar_alloc( size_t > size))). > > ? why? it should return an object already suitable for use..- an instance of FooBar. mybar := self call: #(FooBar foo_bar_alloc( size_t size). self assert: (mybar class == FooBar) At least it was like that in NB. > Note that the handle has one more indirection (it is equivalent to a > foo_bar**) > And when wanting to use a the foo_bar: > > C signature: void foo_use_bar(foo_bar *bar); > self call: #(void foo_use_bar(FooBar self)). > > yep > Still it's not obvious to distinguish why LGitTree has different pointer > arity than LGitDiffOption at first sight... > Naming them LGitTreeHandle or LGitTreePointer is maybe too much? > > i think it expecting a list of options, and if not, then there's a mistake. i don't know much about libgit.. > > this are remaining of old nativeboost and we created the opaque objects to >>> not need this “cheating”… just, I wanted to change them but is a lot of >>> work and I didn’t have the time. >>> >>> I agree it stinks. >>> >>> Esteban >>> >>> On 8 Nov 2017, at 19:06, Nicolas Cellier <nicolas.cellier.aka.nice@gmai >>> l.com> wrote: >>> >>> I was trying to inquire about my latest vm crash in libgit2 >>> >>> https://pharo.fogbugz.com/f/cases/20655/vm-crash-in-libgit-g >>> it_tree_free-throw-suspiscion-on-potential-double-free-problem >>> >>&g
Re: [Pharo-dev] You can cheat in FFI as long as you don't get caught...
On 9 November 2017 at 12:03, Esteban Lorenzano <esteba...@gmail.com> wrote: > yeah, but this is because LGitDiff, LGitRepository and LGitTree (and many > others) are defined as FFIExternalObjects while they should be > FFIOpaqueObjects. Then, the problem is that external objects are *already* > pointers (they have arity 1). > > hmm but the external objects were already designed with thought that it holding some opaque handle to some external object. it does not neccessary should be a pointer .. it could be some handle, that doesn't points directly to some memory location (like in windows api etc). they only difference is only in what function(s) expecting, e.g. if it takes a handle value - you should pass it by value (the handle itself), and when it asks for pointer to the handle (to fill a return value , for instance) - you passing a pointer to it. > this are remaining of old nativeboost and we created the opaque objects to > not need this “cheating”… just, I wanted to change them but is a lot of > work and I didn’t have the time. > > I agree it stinks. > > Esteban > > On 8 Nov 2017, at 19:06, Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com> wrote: > > I was trying to inquire about my latest vm crash in libgit2 > > https://pharo.fogbugz.com/f/cases/20655/vm-crash-in- > libgit-git_tree_free-throw-suspiscion-on-potential-double-free-problem > > when I found this bizarre prototype: > > ^ self > callUnchecked: > #(LGitReturnCodeEnum git_diff_tree_to_tree #(LGitDiff * diff > , LGitRepository repo , LGitTree old_tree , LGitTree new_tree , > LGitDiffOptions * opts)) > options: #() > > While the libgit2 signature differs in indirection levels: > https://libgit2.github.com/libgit2/#v0.19.0/group/diff/ > git_diff_tree_to_tree > > int git_diff_tree_to_tree(git_diff_list **diff, git_repository *repo, > git_tree *old_tree, git_tree *new_tree, const git_diff_options *opts); > > The fact that it does not differs for opts, made me think of a bug... > But no. > > opts is allocated on external c heap with: > > callUnchecked: #(LGitReturnCodeEnum git_diff_init_options(LGitDiffOptions > * self, LGitOptionsVersionsEnum version)) > > int git_diff_init_options(git_diff_options *opts, unsigned int version); > > What you see this time is that signatures match... > So the LGitDiffOptions handle will be an ExternalAddress that will really > point on a git_diff_options > In other words, the handle is a git_diff_options *... > IOW, our LGitDiffOptions object points to an external it_diff_options so > it is what it promises to be. > > For the other structures not so. > We are lying on the level of indirection, so our LGitTree handle are not > really a git_tree *. They are a git_tree **. (an ExternalAddress on a > pointer). > > As long as we lie consistently, it's OK, because it avoids too much > packToArity: unpackToArity: dance. > > That's the "beauty" of C pointers. > We can cast them to whatever or pretend they are handle_for_anything * in > the intermediate level, as long as original producer and final consumer > agree on what it really points to. > > But from code quality perspective, it really stinks. Anyone like me > opening a page to get the exact signature of the function will be > scratching head and loose precious time. Especially when tracking vm crash > down. > > I'm not sure how well it's documented, I presume it's a well known > conscious hack from the original developpers, but such practice really > ought to be discussed here. > > > > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] You can cheat in FFI as long as you don't get caught...
Yes. Signatures of C functions often tells little about correct use of arguments, when there are pointers. And true, without checking the docs & use example, you cannot really make it work correctly, if you will rely only on signature when designing the call to such function(s). It is, in fact, orthogonal to FFI .. it is the way it works in C.. But what is good from FFI part, is that you can design a convenient interface to API that having such functions, in a way, that your users don't need to scratch their heads and stumble upon the code, asking , - hey.. wtf. That's why i said many times, that yes, it is cool to have automatic FFI wrapper generators, but they will never be as good as well thought and designed manually written interfaces to libraries, providing features of a library without burden of strange, bizarre and inconvenient way to pass data between user and library. On 9 November 2017 at 00:06, Nicolas Cellier < nicolas.cellier.aka.n...@gmail.com> wrote: > I was trying to inquire about my latest vm crash in libgit2 > > https://pharo.fogbugz.com/f/cases/20655/vm-crash-in- > libgit-git_tree_free-throw-suspiscion-on-potential-double-free-problem > > when I found this bizarre prototype: > > ^ self > callUnchecked: > #(LGitReturnCodeEnum git_diff_tree_to_tree #(LGitDiff * diff > , LGitRepository repo , LGitTree old_tree , LGitTree new_tree , > LGitDiffOptions * opts)) > options: #() > > While the libgit2 signature differs in indirection levels: > https://libgit2.github.com/libgit2/#v0.19.0/group/diff/ > git_diff_tree_to_tree > > int git_diff_tree_to_tree(git_diff_list **diff, git_repository *repo, > git_tree *old_tree, git_tree *new_tree, const git_diff_options *opts); > > The fact that it does not differs for opts, made me think of a bug... > But no. > > opts is allocated on external c heap with: > > callUnchecked: #(LGitReturnCodeEnum git_diff_init_options(LGitDiffOptions > * self, LGitOptionsVersionsEnum version)) > > int git_diff_init_options(git_diff_options *opts, unsigned int version); > > What you see this time is that signatures match... > So the LGitDiffOptions handle will be an ExternalAddress that will really > point on a git_diff_options > In other words, the handle is a git_diff_options *... > IOW, our LGitDiffOptions object points to an external it_diff_options so > it is what it promises to be. > > For the other structures not so. > We are lying on the level of indirection, so our LGitTree handle are not > really a git_tree *. They are a git_tree **. (an ExternalAddress on a > pointer). > > As long as we lie consistently, it's OK, because it avoids too much > packToArity: unpackToArity: dance. > > That's the "beauty" of C pointers. > We can cast them to whatever or pretend they are handle_for_anything * in > the intermediate level, as long as original producer and final consumer > agree on what it really points to. > > But from code quality perspective, it really stinks. Anyone like me > opening a page to get the exact signature of the function will be > scratching head and loose precious time. Especially when tracking vm crash > down. > > I'm not sure how well it's documented, I presume it's a well known > conscious hack from the original developpers, but such practice really > ought to be discussed here. > > > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] String Interpolation
On 4 October 2017 at 22:30, Igor Stasenko <siguc...@gmail.com> wrote: > > > On 4 October 2017 at 17:27, Sean P. DeNigris <s...@clipperadams.com> > wrote: > >> Igor Stasenko wrote >> > IMO, best would be to make it via compiler plugin. >> >> It seems there is always a tension between newbie-friendliness/purity and >> max-performance/deployment. There are so many other things about a >> Smalltalk >> image that are insecure and any compiler "tricks" are additional places to >> hang up the sizable community that doesn't need that security or >> efficiency. >> Would it be possible to implement it as Sven suggested and then provide a >> compiler plugin as part of a deployment hardening process like we used to >> have where e.g. tools are disabled, etc? >> >> Of course, you can have both: > - the actual implementation of message as fallback when compiler plugin is > not present > - the compiler plugin that does the magic, following same semantics > sorry, i meant 'you MUST have both', not 'you CAN have both' :) > >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> >> > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] String Interpolation
On 4 October 2017 at 12:46, Denis Kudriashov <dionisi...@gmail.com> wrote:
> Hi Igor.
>
> Did you see that we have now #asMethodConstant?
>
> DateAndTime now asMethodConst
>
>
> It is not compiled time but behaviour is very close to it.
> The trick is that first time execution will replace full expression with
> the result as literal (the receiver of #asMethodConst). So at second time
> it will be just literal reading.
>
> Aha. Nice. But that useful only for constant expressions, i.e. when you
need to reformat static data.
Not quite fits for use case coined by Sven in this topic.
> 2017-10-04 11:36 GMT+02:00 Igor Stasenko <siguc...@gmail.com>:
>
>> IMO, best would be to make it via compiler plugin.
>>
>> Same, as i proposed for object literals,
>> a compiler could detect a pattern interpolate
>> and replace it at compile time to produce/expand it into proper
>> context-aware semantic, something like this:
>>
>> {'a' . x . 'b' . y. 'c' .z } gather: #asString
>>
>> That will allow to eliminate run-time security risk(due to #evaluate:),
>> as well as run-time execution cost,
>> and allows a nice and convenient and clean syntax.
>>
>> Without compiler modification, it's hard to reach best security &
>> performance & convenience ideals.
>>
>>
>>
>> On 4 October 2017 at 11:06, Thierry Goubier <thierry.goub...@gmail.com>
>> wrote:
>>
>>>
>>>
>>> 2017-10-04 9:50 GMT+02:00 Guillermo Polito <guillermopol...@gmail.com>:
>>>
>>>> if the compiler plugin correctly models such special syntax with
>>>> special AST nodes, that could be even possible without much effort
>>>>
>>>
>>> Interesting. Would that imply that by having those special ast nodes, we
>>> would get the decompilation working for the debugger?
>>>
>>> Thierry
>>>
>>>
>>>
>>>
>>>>
>>>> On Tue, Oct 3, 2017 at 5:42 PM, Denis Kudriashov <dionisi...@gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>> 2017-10-03 17:39 GMT+02:00 Denis Kudriashov <dionisi...@gmail.com>:
>>>>>
>>>>>> Hi.
>>>>>>
>>>>>> While idea looks cool it will require a lot of tool support. Senders,
>>>>>> var/class references, rename refactorings should be aware of it
>>>>>>
>>>>>
>>>>> And I forgot debugger. It should be possible to step over
>>>>> "interpolated expressions"
>>>>>
>>>>>
>>>>>>
>>>>>> 2017-10-03 17:29 GMT+02:00 Damien Pollet <damien.pol...@gmail.com>:
>>>>>>
>>>>>>> On 3 October 2017 at 14:07, Guillermo Polito <
>>>>>>> guillermopol...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Why not having an opal plugin?
>>>>>>>>
>>>>>>>> The opal plugin may read strings in the form:
>>>>>>>>
>>>>>>>> "lalala {some expression} lololo"
>>>>>>>>
>>>>>>>> and replace at compile time that by:
>>>>>>>>
>>>>>>>> "lalala {1} lololo" format { some expression }
>>>>>>>>
>>>>>>>
>>>>>>> If we're going to extend the compiler, we might as avoid parsing at
>>>>>>> runtime by desugaring more like:
>>>>>>>
>>>>>>> String streamContents: [:str |
>>>>>>> str
>>>>>>> nextPutAll: 'lalala ';
>>>>>>> nextPutAll: (some expression) printString;
>>>>>>> nextPutAll: ' lololo' ]
>>>>>>>
>>>>>>> The thing to think about is what is the delimiter for {some
>>>>>>>> expression}.
>>>>>>>> - a too used one may break lots of existing code.
>>>>>>>>
>>>>>>>
>>>>>>> …or we could change the string quotes to mean "dynamic string in
>>>>>>> which interpolations can be used" and keep single quotes for literal
>>>>>>> strings only.
>>>>>>>
>>>>>>> - and we should escape it
>>>>>>>>
>>>>>>>
>>>>>>> indeed
>&
Re: [Pharo-dev] String Interpolation
On 4 October 2017 at 17:27, Sean P. DeNigris <s...@clipperadams.com> wrote: > Igor Stasenko wrote > > IMO, best would be to make it via compiler plugin. > > It seems there is always a tension between newbie-friendliness/purity and > max-performance/deployment. There are so many other things about a > Smalltalk > image that are insecure and any compiler "tricks" are additional places to > hang up the sizable community that doesn't need that security or > efficiency. > Would it be possible to implement it as Sven suggested and then provide a > compiler plugin as part of a deployment hardening process like we used to > have where e.g. tools are disabled, etc? > > Of course, you can have both: - the actual implementation of message as fallback when compiler plugin is not present - the compiler plugin that does the magic, following same semantics > > > - > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] String Interpolation
t;> >
>>>>>>> > I got into a little office discussion about string interpolation
>>>>>>> as it is done in different programming languages.
>>>>>>> >
>>>>>>> > In Pharo we have String>>#format: which is pretty nice. It works
>>>>>>> as follows:
>>>>>>> >
>>>>>>> > | x y |
>>>>>>> > x := 123.
>>>>>>> > y := #foo.
>>>>>>> > 'x={1} and y={2}' format: { x. y }.
>>>>>>> >
>>>>>>> > It is also possible to use a dictionary with keys, like this:
>>>>>>> >
>>>>>>> > | x y |
>>>>>>> > x := 123.
>>>>>>> > y := #foo.
>>>>>>> > 'x={x} and y={y}' format: { #x->x. #y->y } asDictionary.
>>>>>>> >
>>>>>>> > But this is not true string interpolation as described in [
>>>>>>> https://en.wikipedia.org/wiki/String_interpolation ]. The idea is
>>>>>>> to write the value generating expressions directly inside the strings.
>>>>>>> >
>>>>>>> > Since in Pharo we add features not by extending the syntax but by
>>>>>>> adding messages I wondered if it could be done for string interpolation.
>>>>>>> The goal is to make the following work:
>>>>>>> >
>>>>>>> > | x y |
>>>>>>> > x := 123.
>>>>>>> > y := #foo.
>>>>>>> > 'It seems x equals {x} and y equals {y} while Pi is still {Float
>>>>>>> pi}' interpolate.
>>>>>>> >
>>>>>>> > => 'It seems x equals 123 and y equals foo while Pi is still
>>>>>>> 3.141592653589793'
>>>>>>> >
>>>>>>> > Here is the implementation I came up with:
>>>>>>> >
>>>>>>> > String>>#interpolate
>>>>>>> > "Format the receiver by interpolating the evaluation of
>>>>>>> expressions
>>>>>>> > in between curly brackets in the context of the sender as in the
>>>>>>> following 3 oneline examples.
>>>>>>> > 'Today is {Date today}' interpolate.
>>>>>>> > | x | x := 123. 'x equals {x} and pi equals {Float pi}'
>>>>>>> interpolate.
>>>>>>> > 'In {#strings} you can escape \{ by prefixing it with \\'
>>>>>>> interpolate."
>>>>>>> >
>>>>>>> > | senderContext |
>>>>>>> > senderContext := thisContext sender.
>>>>>>> > ^ self class new: self size streamContents: [ :out | | stream |
>>>>>>> > stream := self readStream.
>>>>>>> > [ stream atEnd ] whileFalse: [ | currentChar |
>>>>>>> > (currentChar := stream next) == ${
>>>>>>> > ifTrue: [ | expression result |
>>>>>>> > expression := stream upTo: $}.
>>>>>>> > result := Compiler new
>>>>>>> > evaluate: expression in: senderContext to: nil
>>>>>>> notifying: nil ifFail: [ ^ nil ] logged: false.
>>>>>>> > out nextPutAll: result asString ]
>>>>>>> > ifFalse: [
>>>>>>> > currentChar == $\
>>>>>>> > ifTrue: [ stream atEnd ifFalse: [ out nextPut:
>>>>>>> stream next ] ]
>>>>>>> > ifFalse: [ out nextPut: currentChar ] ] ] ]
>>>>>>> >
>>>>>>> > It is a hack that could certainly be improved. And there is of
>>>>>>> course an obvious security problem.
>>>>>>> >
>>>>>>> > Thoughts ?
>>>>>>> >
>>>>>>> > Sven
>>>>>>> >
>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>>
>>>>>>
>>>>>> Guille Polito
>>>>>>
>>>>>> Research Engineer
>>>>>>
>>>>>> Centre de Recherche en Informatique, Signal et Automatique de Lille
>>>>>>
>>>>>> CRIStAL - UMR 9189
>>>>>>
>>>>>> French National Center for Scientific Research - *http://www.cnrs.fr
>>>>>> <http://www.cnrs.fr>*
>>>>>>
>>>>>>
>>>>>> *Web:* *http://guillep.github.io* <http://guillep.github.io>
>>>>>>
>>>>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Damien Pollet
>>>>> type less, do more [ | ] http://people.untyped.org/damien.pollet
>>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>>
>>
>>
>> Guille Polito
>>
>> Research Engineer
>>
>> Centre de Recherche en Informatique, Signal et Automatique de Lille
>>
>> CRIStAL - UMR 9189
>>
>> French National Center for Scientific Research - *http://www.cnrs.fr
>> <http://www.cnrs.fr>*
>>
>>
>> *Web:* *http://guillep.github.io* <http://guillep.github.io>
>>
>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>>
>
>
--
Best regards,
Igor Stasenko.
Re: [Pharo-dev] Pharo 6 screenshot
Great! On 25 April 2017 at 10:52, Alexandre Bergel <alexandre.ber...@me.com> wrote: > You are an artist! > > Alexandre > > > > On Apr 24, 2017, at 11:48 PM, Pavel Krivanek <pavel.kriva...@gmail.com> > wrote: > > > > Right, next try... > > > > https://goo.gl/photos/YnGoZTrpKjJnSbFU9 > > > > -- Pavel > > > > > > > > 2017-04-24 22:22 GMT+02:00 Cyril Ferlicot D. <cyril.ferli...@gmail.com>: > > Le 24/04/2017 à 22:13, Pavel Krivanek a écrit : > > > New version: > > > > > > https://goo.gl/photos/66Yz3pSSK62aTYV66 > > > > > > -- Pavel > > > > > > > Pretty nice but too blurry for me. Especially on the right of the screen. > > > > But maybe it's just me. > > > > -- > > Cyril Ferlicot > > https://ferlicot.fr > > > > http://www.synectique.eu > > 2 rue Jacques Prévert 01, > > 59650 Villeneuve d'ascq France > > > > > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] [Vm-dev] [ANN] PharoNOS
On 23 March 2017 at 00:03, Ronie Salgado <ronies...@gmail.com> wrote:
>
> Hi,
>
> With the experimental Lowcode backend for the UFFI, it is possible to call
> functions with almost arbitrary calling conventions. For some of the
> special assembly instructions that are required by this project, I could
> add the following extra instruction:
> - storeIntoSpecialRegister: {CR0, CR1, CR2, CR3, CR4, CR5, GDT, LDT, IDT)
> - loadFromSpecialRegister:
> - loadFromIOPortU?Int{8,16,32}:
> - storeIntoIOPortU?Int{8,16,32}:
>
> As for the interruptions, there are far trickier because they can be
> triggered in any time. They probably would require some special trampoline
> for storing/restoring the VM state, something similar to the callbacks.
>
> Currently I am finishing a refactoring of the Lowcode register allocator,
> so the Lowcode VM is out of service for this week :) .
>
> Hey, guys, i'd like to stress, that AsmJit
>> is quite standalone part of NB, and nothing prevents you to use it in own
>> way, not the way NB was..
>> Because NB was born to make nice integration between machine code and VM
>> , and providing FFI,
>> and as a demonstration that generating machine code IS possible and quite
>> doable from within an image.
>>
>> But there's a tons of ways how you could generate machine code, and then
>> use it outside the scope of FFI.
>> You could just make own llittle primitive, that just makes a call on
>> arbitrary address, and put your generated code on it.. Voila.
>> Again, you could store generated code not in method(s) trailer , but
>> somewhere else.. it just up to you, after all.
>> For instance i had parts that were storing generated code directly in
>> COG's JITter, replacing its primitive section.
>> So, that make a nice integration with JIT, that just using your code as a
>> primitive for given method..
>> All is doable, when you working at lowest level, you just need to think
>> how to expose it in convenient way.
>>
>
> For GPU compilation, I implemented a SSA based intermediate representation
> very similar to the one used by LLVM. As a experiment, I did a very basic
> machine code generator which can produce relocatable ELF32 and ELF64 object
> files, which can be linked with any C library or program. With this I
> managed to implement a basic ahead of time compiled Smalltalk runtime.
>
> Before starting that backend, I took a look on AsmJit and the VirtualCPU
> and I did not like the dependencies and some details about the stack.
> However, now I do not like the low level backend so I started refactoring
> into a separate package, but I still think that I should take yet another
> look to AsmJit and the VirtualCPU, so I am wondering where is actually
> located the latest version of these two projects.
>
> IIRC, the stack (but more precisely - temporaries) management in AsmJIT
are implemented in own classes, that doing the job of allocating stack
space and assigning each temporary to specific place on stack.
As well, as calling convention. Nothing prevents you from adding own by
implementing their protocol(s).
Or you may leave it as a whole, except that then you'll have to handle it
by yourself. And of course, it is already there, since initial version has
no such functionality at all,
all you have to do is to tell:
asm noStackFrame.
And so, it will leave you without it.
As for where it located - see at smalltalkhub , if i remember Max were
working on that and made quite complete coverage of ARM instruction set. (
http://smalltalkhub.com/#!/~maxmattone/AsmJit-ARM)
I don't remember if we merged the ARM support into main branch.. But i
think you can figure it out.
P.S. ohh, you see.. it just never ending quest to keep dispelling people's
perception, that there's something impossible or wrong with these things
or that's there are something that won't make things possible.. So, they
choose to go with C :)
Best regards,
> Ronie
>
>
--
Best regards,
Igor Stasenko.
Re: [Pharo-dev] [ANN] PharoNOS
Hey, guys, i'd like to stress, that AsmJit is quite standalone part of NB, and nothing prevents you to use it in own way, not the way NB was.. Because NB was born to make nice integration between machine code and VM , and providing FFI, and as a demonstration that generating machine code IS possible and quite doable from within an image. But there's a tons of ways how you could generate machine code, and then use it outside the scope of FFI. You could just make own llittle primitive, that just makes a call on arbitrary address, and put your generated code on it.. Voila. Again, you could store generated code not in method(s) trailer , but somewhere else.. it just up to you, after all. For instance i had parts that were storing generated code directly in COG's JITter, replacing its primitive section. So, that make a nice integration with JIT, that just using your code as a primitive for given method.. All is doable, when you working at lowest level, you just need to think how to expose it in convenient way. -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Esteban's ChangeLog week of 6 March 2017
On 13 March 2017 at 09:00, <esteba...@gmail.com> wrote: > Hello! > > This is my weekly ChangeLog, from 6 March 2017 to 12 March 2017. > You can see it in a better format by going here: > http://log.smallworks.eu/web/search?from=6/3/2017=12/3/2017 > > ChangeLog > = > > 10 March 2017: > -- > > *=== libgit2(ssh) and linux > An update on the libgit2 (and consequently iceberg) problem on linux: > SSH will not work on ITIMER VM (which > is the zeroconf default, at least for now). > > Here the reason: > > ITIMER sends an signal to the VM thread using > +pthread_kill(tickerThread, TICKER_SIGNAL)+ and that aborts > system calls, which are used by +libssh2+, producing a 'wait for > packet' to fail answering a timeout ( > even if that timeout does not happens for real). > > Here is an interesting comment from +sqUnixITimerTickerHeartbeat.c+ : > > > /* While we use SA_RESTART to ensure system calls are restarted, this > is > * not universally effective. In particular, connect calls can abort > if > * a system call is made in the signal handler, i.e. the pthread_kill > in > * prodHighPriorityThread. So we avoid this if possible by not > prodding > * the high-priority thread unless there are high-priority tickees as > * indicated by numAsyncTickees > 0. > */ > > > ... and sadly, as +OSSubprocess+, +libssh2+ calls falls under the > category of "not universally effective" > (they are connect calls... once disconnected, you cannot connect again > 'as is'). > > So, the only workaround possible (at least for now), is to use the > threaded version of VM... I improved the > error message it throws when this fails, now looks like this: > > > This VM uses a thread heartbeat who requires a special configuration > to work. > You need to allow it to run higher priority threads (real time), to > allow clock to work properly > You need to add a conf file to /etc/security/limits.d, executing this: > > sudo cat >/etc/security/limits.d/%s.conf <<END\n", VMNAME); > * hardrtprio 2 > * softrtprio 2 > END > > You need to log out and log back in for the limits to take effect. > For more information read https://github.com/ > OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux > > > which at least shows what's happens and how you can easily fix it. > > Now, I think this is a *sad solution*. Needing to touch system > configuration in order to run a VM > does not feels "professional". I would like to have some time to find > a fix. > No, it does feels right, according to common *nix lifestyle :) No, seriously, it is not an issue for linux to set up configs for installed software , that would require root privileges. VM is quite a beast, and this is not a surprise, that it requires fine tuning & deep & broader interfacing with OS, comparing to regular software. Of course, the sad moment is that you need to write down an installation package and put this .conf file there which will install it, in comparison to usual "download and run" style, this surely looks like a drawback. But we can do smarter: - add small script to bundle with big letters "RUN ME" , that will do what is should to copy/concat .conf file for VM binary located at given folder or wherever it does.. and everyone's happy :) > > > 9 March 2017: > - > > *I spent last two days again fighting with linux dependencies, because > what I thought was fixed (the > loading of +libgit2.so+), actually was not working in all conditions. > > Now, I think I finally arrived to a working solution (that involved > add an +rpath+ to Pharo, not > to dependent libraries). > > There is a new +vmLatest60+, let's see how it works... > > > 6 March 2017: > ----- > > *I spent time fixing libgit2 (and dependents) compilation, both for > linux and windows. > > As a result, now windows is working again (there was problems after > version 0.26)... but linux, who seemed > working last friday, is now again not working properly :( > > > cheers! > Esteban > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] [Pharo-users] What is the craziest bug you ever face
I don't think my reply will be anything useful, but as to me the most craziest bug is metabug, i.e. when system doesn't provides any means to debug things. :) As for regular bugs .. it is quite hard to remember anything i wasn't able to deal with, given enough time & effort, and then emphasize single case over the rest. And since human brains tend to forget unpleasant things, there's not much details to tell and remember. On 9 March 2017 at 13:36, Stephane Ducasse <stepharo.s...@gmail.com> wrote: > Hi guys > > During the DSU workshop we were brainstorming about what are the most > difficult bugs we faced and what are the conceptual tools that would have > helped you. > > Stef > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Pharo bootstrap with Ring and Calypso
Hmm.. what causing such huge computation cost? Half an hour to bootstrap 600k.. sounds like unrealistically high. All you need to do is to build a graph in memory and then serialize it.. so what it does extra to make it so slow? On 28 February 2017 at 15:03, Guillermo Polito <guillermopol...@gmail.com> wrote: > Hi, > > yes this is cool :) > > There is also a new smart student that will work on this infrastructure a > bit to make it "normal developer friendly", you know, hiding some > implementation details, making maybe a UI for the process and so on. > > Now, about the questions: > > - And how much smaller could the image get if the class builder was > removed? > >Well, as Pavel says, you can get for example 10K. You can get even less > if you tweak it manually. Around 10k is the minimal required by the VM to > run a full featured image (at least in cog 32 bits, I did not measure it in > Spur). Imagine that the VM requires at least: > * one process scheduler > * one process in that scheduler > * one context on that process > * one method on that context > >Then, the VM requires some information to interact with the runtime, > e.g., > * what is the selector used for doesNotUnderstand: (yes, we can > change it!) > * what are the first 256 character objects in the Character flyweight > * what is the class of SmallInteger immediate instances > * some special/optimized selectors > > My automatic process generated a somewhat 10k of objects required for > this VM/image interaction. > > Of course this list changes a bit with Spur, and could be reduced (for > example, if you don't use characters, you wouldn't need the character > flyweight and so on...) > > - Is it future approach for bootstrap? (with respect to the 10k image) > > Well, if you read my thesis, what I'm doing there is to lazily pick what > classes and methods will go inside an image. While this is nice to > experiment, I do not think It's a good approach for bootstrapping: >* you need to exercise/execute all possible cases your image needs to > support >* and that means you need to know all those cases in advance >* and that you have to be careful with side effects > >Otherwise, code not executed is not taken in the resulting image. > > Also take the fact that changing a little line of code may result in > bootstrapping an image a couple of times bigger because of a wrong > dependency. > > All these points make this approach less reproducible and a bit more > complicated. I prefer an explicit list of packages to bootstrap, that we > can control and really test the output :) > > Also, as Igor says, we could be able to generate an image without a class > builder, as we are able to generate an image without a compiler. But we do > not want to. Because that is an image that we cannot almost interact with. > We cannot load code inside. So the more interesting question is where is > the balance between space and functionality. > > BTW Pavel, this approach may need to be updated but I think we could make > it run on top of the simulator also ;). > > - How faster or slower bootstrap process with it? > > They are not really comparable. They do not use the same infrastructure, > nor the same process, and they do not generate the same results. > The 10k image is of course generated in a matter of seconds, but a 600k > image containing the seaside counter may take half an hour. > > In our current approach, the speed of bootstrap is directly related to > the number of classes and methods inside the result. There are two ways to > speed up the process: > - by speeding up the ast interpreter (or replacing it by a compiled > version of it) > - and by cleaning the kernel > > > > Guille > > On Fri, Feb 24, 2017 at 9:15 PM, Igor Stasenko <siguc...@gmail.com> wrote: > >> >> >> On 24 February 2017 at 21:01, Pavel Krivanek <pavel.kriva...@gmail.com> >> wrote: >> >>> >>> 2017-02-24 17:17 GMT+01:00 Denis Kudriashov <dionisi...@gmail.com>: >>> >>>> >>>> 2017-02-24 16:36 GMT+01:00 Pavel Krivanek <pavel.kriva...@gmail.com>: >>>> >>>>> The "guest" object memory runs in a special virtual machine simulator >>>>> during the bootstrapping. That simulator uses AST Interpreter to execute >>>>> the code inside the guest environment before it is installed for real. It >>>>> uses own special kind of proxies and tricks to do it. The current >>>>> bootstrap >>>>> cannot run without class builder in the guest envir
Re: [Pharo-dev] Epicea user experience report
Epicea is most valuable jewel i ever wished to have in Pharo.. Martin big thanks for your effort to make such a wonderful piece of software. -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Any idea for a cool name for the remote tool suite?
Call it Java[tm] .. .. what? i heard it is quite popular. albeit fuzzy wuzzy :) P.S. just call it Pharo-Remote and let it go -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Pharo bootstrap with Ring and Calypso
On 24 February 2017 at 21:01, Pavel Krivanek <pavel.kriva...@gmail.com> wrote: > > 2017-02-24 17:17 GMT+01:00 Denis Kudriashov <dionisi...@gmail.com>: > >> >> 2017-02-24 16:36 GMT+01:00 Pavel Krivanek <pavel.kriva...@gmail.com>: >> >>> The "guest" object memory runs in a special virtual machine simulator >>> during the bootstrapping. That simulator uses AST Interpreter to execute >>> the code inside the guest environment before it is installed for real. It >>> uses own special kind of proxies and tricks to do it. The current bootstrap >>> cannot run without class builder in the guest environment, but... >>> >>> >>>> And how much smaller could the image get if the class builder was >>>> removed. >>>> >>> >>> ...Guille in his thesis tried different approaches and he was able to >>> produce extremely small images (~10 KiB) that did for example only a sum >>> of two numbers. >>> >> >> Is it future approach for bootstrap? >> How faster or slower bootstrap process with it? >> > > That's more question for Guille, but I do not think we will adopt this > approach of bootstrapping in near future because it needs to be updated for > the Spur format and it needs a special VM modifications. And the question > is how much is it really needed because if you want to do something with > the image, you will anyway need most of methods needed for the class > builder like basic strings and collections support. > > I think, you can shrink image even more, by running something after booting it to remove ClassBuilder & co, if you don't need to create classes etc. -- Best regards, Igor Stasenko.
Re: [Pharo-dev] athens dead code?
On 29 January 2017 at 19:16, stepharong <stephar...@free.fr> wrote: > On Sun, 29 Jan 2017 17:21:44 +0100, Igor Stasenko <siguc...@gmail.com> > wrote: > > > > On 29 January 2017 at 16:16, stepharong <stephar...@free.fr> wrote: > >> >> >> On 27 January 2017 at 00:06, stepharong <stephar...@free.fr> wrote: >> >>> >>> Yes because it if keep dead code around we will have a broken house >> window syndrome and I do not like it. >> > > You don't have to advocate that to me. I am fully on your side with this :) > > excellent! > > Can you propose a slice so that we fix the code? > Right now i can only propose if someone else propose the slice.. I don't have much free time on doing things on the side, even if i would like to do it... I am not the God, and as you know already , my brains working well only if they are in single-threaded mode :) -- Best regards, Igor Stasenko.
Re: [Pharo-dev] athens dead code?
On 29 January 2017 at 16:16, stepharong <stephar...@free.fr> wrote: > > > On 27 January 2017 at 00:06, stepharong <stephar...@free.fr> wrote: > >> >> Yes because it if keep dead code around we will have a broken house > window syndrome and I do not like it. > You don't have to advocate that to me. I am fully on your side with this :) -- Best regards, Igor Stasenko.
Re: [Pharo-dev] athens dead code?
Ah, yeah.. one important note: #sendCommandsTo: is used to convert backend-neutral path data to backend-specific paths. That means , that commands that implementor should use , should conform with AthensPathBuilder protocol, so that you can later do: backendSpecificPath := canvas createPath: [:builder | myBackendNeutralPathData sendCommandsTo: builder]. On 29 January 2017 at 17:41, Igor Stasenko <siguc...@gmail.com> wrote: > > > On 29 January 2017 at 16:16, stepharong <stephar...@free.fr> wrote: > >> >> >> On 27 January 2017 at 00:06, stepharong <stephar...@free.fr> wrote: >> >>> >>> accept: aVisitor >>> ^ aVisitor lineSegment: self >>> accept: aVisitor >>> ^ aVisitor closeSegment: self >>> accept: aVisitor >>> ^ aVisitor moveSegment: self >>> >>> seems to invoke methods that do not exit >>> I check AthensLIneSegment is used so I do not understand why the methods >>> are broken. >>> >>> this is a part of visitor api for path segments. >> >> >>> I know but where is the visitor? >>> >>> if you remove it, then users cannot use it >>> for iterating trough path segments for converting them etc etc.. >>> of course, it may be nit used by Athens itself.. but it doesn't means it >>> is useless. >>> >>> >>> Where is the visitor? Why accept: are not packaged with it? Does it use >>> DNU trick? >>> In my imagine there is no implementor of moveSegment: closeSegment: >>> >>> >>> why there should be any, if nobody using this feature, yet? so you don't >> have a single visitor. >> you could add a test case for coverage, so it won't bother you that >> there's no implementors of >> given selector in image :) >> >> >> Yes because it if keep dead code around we will have a broken house >> window syndrome and I do not like it. >> >> iirc, i used it for path transformation(s) code.. which then get removed. >> >> >> Was it removed because it was not good, ? no useful? or just a mistake? >> >> >> well, i think there's some kind of duplication. > if you look at base class - AthensPathSegment > there's two methods for visitor pattern: > #accept: > and > #sendCommandsTo: > > > the main difference between the above two is that > #accept: should double-dispatch with appropriate message passing single > argument - the receiver, > while > > > #sendCommandTo: is used by a convenience protocol #sendCommandsTo: > that sends direct _series_ of commands to visitor in a fashion like: > visitor lineTo: aPoint; > curveVia: aPoint to: endPoint > etc. > > Mainly, sendCommandsTo: is for convenience, that does not requires the > user to implement a loop in own code, > and to allow user to deal directly with data instead of subinstances of > AthensPathSegment. > > Also, as i looking into code, there are some leftovers - the > #convertWith:, and #visitWith: . These should be removed and users of > #visitWith: should be > refactored to #accept: protocol. To not confuse users what exactly > protocol should be used. > > > > >> -- >> Best regards, >> Igor Stasenko. >> >> >> >> >> -- >> Using Opera's mail client: http://www.opera.com/mail/ >> > > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] athens dead code?
On 29 January 2017 at 16:16, stepharong <stephar...@free.fr> wrote: > > > On 27 January 2017 at 00:06, stepharong <stephar...@free.fr> wrote: > >> >> accept: aVisitor >> ^ aVisitor lineSegment: self >> accept: aVisitor >> ^ aVisitor closeSegment: self >> accept: aVisitor >> ^ aVisitor moveSegment: self >> >> seems to invoke methods that do not exit >> I check AthensLIneSegment is used so I do not understand why the methods >> are broken. >> >> this is a part of visitor api for path segments. > > >> I know but where is the visitor? >> >> if you remove it, then users cannot use it >> for iterating trough path segments for converting them etc etc.. >> of course, it may be nit used by Athens itself.. but it doesn't means it >> is useless. >> >> >> Where is the visitor? Why accept: are not packaged with it? Does it use >> DNU trick? >> In my imagine there is no implementor of moveSegment: closeSegment: >> >> >> why there should be any, if nobody using this feature, yet? so you don't > have a single visitor. > you could add a test case for coverage, so it won't bother you that > there's no implementors of > given selector in image :) > > > Yes because it if keep dead code around we will have a broken house window > syndrome and I do not like it. > > iirc, i used it for path transformation(s) code.. which then get removed. > > > Was it removed because it was not good, ? no useful? or just a mistake? > > > well, i think there's some kind of duplication. if you look at base class - AthensPathSegment there's two methods for visitor pattern: #accept: and #sendCommandsTo: the main difference between the above two is that #accept: should double-dispatch with appropriate message passing single argument - the receiver, while #sendCommandTo: is used by a convenience protocol #sendCommandsTo: that sends direct _series_ of commands to visitor in a fashion like: visitor lineTo: aPoint; curveVia: aPoint to: endPoint etc. Mainly, sendCommandsTo: is for convenience, that does not requires the user to implement a loop in own code, and to allow user to deal directly with data instead of subinstances of AthensPathSegment. Also, as i looking into code, there are some leftovers - the #convertWith:, and #visitWith: . These should be removed and users of #visitWith: should be refactored to #accept: protocol. To not confuse users what exactly protocol should be used. > -- > Best regards, > Igor Stasenko. > > > > > -- > Using Opera's mail client: http://www.opera.com/mail/ > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] athens dead code?
On 27 January 2017 at 09:17, stepharong <stephar...@free.fr> wrote: > On Fri, 27 Jan 2017 00:31:11 +0100, Igor Stasenko <siguc...@gmail.com> > wrote: > > > > On 27 January 2017 at 00:06, stepharong <stephar...@free.fr> wrote: > >> >> accept: aVisitor >> ^ aVisitor lineSegment: self >> accept: aVisitor >> ^ aVisitor closeSegment: self >> accept: aVisitor >> ^ aVisitor moveSegment: self >> >> seems to invoke methods that do not exit >> I check AthensLIneSegment is used so I do not understand why the methods >> are broken. >> >> this is a part of visitor api for path segments. > > > I know but where is the visitor? > > if you remove it, then users cannot use it > for iterating trough path segments for converting them etc etc.. > of course, it may be nit used by Athens itself.. but it doesn't means it > is useless. > > > Where is the visitor? Why accept: are not packaged with it? Does it use > DNU trick? > In my imagine there is no implementor of moveSegment: closeSegment: > > > why there should be any, if nobody using this feature, yet? so you don't have a single visitor. you could add a test case for coverage, so it won't bother you that there's no implementors of given selector in image :) iirc, i used it for path transformation(s) code.. which then get removed. -- Best regards, Igor Stasenko.
Re: [Pharo-dev] memoized vs once
On 27 January 2017 at 03:45, Igor Stasenko <siguc...@gmail.com> wrote:
>
>
> On 27 January 2017 at 02:28, Ben Coman <b...@openinworld.com> wrote:
>
>> On Fri, Jan 27, 2017 at 7:35 AM, Igor Stasenko <siguc...@gmail.com>
>> wrote:
>> >
>> >
>> > On 27 January 2017 at 01:30, Ben Coman <b...@openinworld.com> wrote:
>> >>
>> >> On Fri, Jan 27, 2017 at 6:02 AM, stepharong <stephar...@free.fr>
>> wrote:
>> >> > On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann <asta...@gmx.de
>> >
>> >> > wrote:
>> >> >
>> >> >> stepharong wrote:
>> >> >>>
>> >> >>> can we rename this selector?
>> >> >>> asMethodConst should be at least be renamed to asConstantMethod
>> >> >>
>> >> >>
>> >> >> When you use "as {something}" then "something" depicts the result of
>> >> >> the
>> >> >> conversion message sent to an object.
>> >> >>
>> >> >> Like in #asNumber or #asString which shows to what the receiver
>> will be
>> >> >> converted.
>> >> >
>> >> >
>> >> > Yes I thought that it was doing that.
>> >> >>
>> >> >>
>> >> >>
>> >> >> My understanding is that in the case discussed the receiver object
>> is
>> >> >> NOT converted to a constant unchangeable method, so
>> #asConstantMethod
>> >> >> would
>> >> >> not fit as a selector.
>> >> >>
>> >> >> Instead it is sent to an object that afterwards is a constant
>> within a
>> >> >> method
>> >> >> (so it will not be evaluated later at runtime again) so IMHO
>> >> >> #asMethodConstant
>> >> >> instead of #asMethodConst would be better.
>> >> >
>> >> >
>> >> > I do not understand any of them.
>> >>
>> >> method constant = constant of a method
>>
>>
>> >> constant method = method that does not change
>> >>
>> > are you sure?
>>
>> pretty sure. 'method' is the subject. 'constant' is the adjective that
>> modifies the subject.
>> Its a bit hard to explain that intrinsic feeling of what is right,
>> but maybe If the adjective follows the subject its usually
>> separated by little joining words.
>> http://www.grammar-monster.com/glossary/adjective_definition.htm
>>
>> > maybe it is
>> > constant method = method that returns constant?
>>
>> For me this does not compute.
>> But I understand rules differ in other languages and its hard to avoid
>> subtle influences from your primary language.
>>
>
> heh.. you see my pain! right now i have to deal with C++
> and seeing all these
> const Type & foo const..
> and cannot parse it..
> :)
>
> And still, it could just be my personal bias.
>> So if you & Stef find it ambiguous, it may be for others and we should
>> aim to avoid that.
>>
>> Well, we have more general term for objects that do not change over their
> lifetime - immutable. And it is moare precise,
>
(or if not general, but well settled)
> if we're talking in smalltalk context.
> So, why borrowing rather alien term into our ecosystem, because i barely
> heard that anyone
> were using it, and saying something like 'constant object' or something
> like this, when talking smalltalk context.
>
> Because when you open this 'can' of constant method, what does it means
> being a constant?
> Is is that method's properties won't change, or all object(s) it is
> pointing to never change as well?
>
>
>> cheers -ben
>>
>> >
>> > apparently, that's why 'constant' term doesn't fits there, because
>> there's
>> > so many confusion about it. what are the constant in dynamic system,
>> after
>> > all?
>>
>>
>
>
> --
> Best regards,
> Igor Stasenko.
>
--
Best regards,
Igor Stasenko.
Re: [Pharo-dev] memoized vs once
On 27 January 2017 at 02:28, Ben Coman <b...@openinworld.com> wrote:
> On Fri, Jan 27, 2017 at 7:35 AM, Igor Stasenko <siguc...@gmail.com> wrote:
> >
> >
> > On 27 January 2017 at 01:30, Ben Coman <b...@openinworld.com> wrote:
> >>
> >> On Fri, Jan 27, 2017 at 6:02 AM, stepharong <stephar...@free.fr> wrote:
> >> > On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann <asta...@gmx.de>
> >> > wrote:
> >> >
> >> >> stepharong wrote:
> >> >>>
> >> >>> can we rename this selector?
> >> >>> asMethodConst should be at least be renamed to asConstantMethod
> >> >>
> >> >>
> >> >> When you use "as {something}" then "something" depicts the result of
> >> >> the
> >> >> conversion message sent to an object.
> >> >>
> >> >> Like in #asNumber or #asString which shows to what the receiver will
> be
> >> >> converted.
> >> >
> >> >
> >> > Yes I thought that it was doing that.
> >> >>
> >> >>
> >> >>
> >> >> My understanding is that in the case discussed the receiver object is
> >> >> NOT converted to a constant unchangeable method, so #asConstantMethod
> >> >> would
> >> >> not fit as a selector.
> >> >>
> >> >> Instead it is sent to an object that afterwards is a constant within
> a
> >> >> method
> >> >> (so it will not be evaluated later at runtime again) so IMHO
> >> >> #asMethodConstant
> >> >> instead of #asMethodConst would be better.
> >> >
> >> >
> >> > I do not understand any of them.
> >>
> >> method constant = constant of a method
>
>
> >> constant method = method that does not change
> >>
> > are you sure?
>
> pretty sure. 'method' is the subject. 'constant' is the adjective that
> modifies the subject.
> Its a bit hard to explain that intrinsic feeling of what is right,
> but maybe If the adjective follows the subject its usually
> separated by little joining words.
> http://www.grammar-monster.com/glossary/adjective_definition.htm
>
> > maybe it is
> > constant method = method that returns constant?
>
> For me this does not compute.
> But I understand rules differ in other languages and its hard to avoid
> subtle influences from your primary language.
>
heh.. you see my pain! right now i have to deal with C++
and seeing all these
const Type & foo const..
and cannot parse it..
:)
And still, it could just be my personal bias.
> So if you & Stef find it ambiguous, it may be for others and we should
> aim to avoid that.
>
> Well, we have more general term for objects that do not change over their
lifetime - immutable. And it is moare precise,
if we're talking in smalltalk context.
So, why borrowing rather alien term into our ecosystem, because i barely
heard that anyone
were using it, and saying something like 'constant object' or something
like this, when talking smalltalk context.
Because when you open this 'can' of constant method, what does it means
being a constant?
Is is that method's properties won't change, or all object(s) it is
pointing to never change as well?
> cheers -ben
>
> >
> > apparently, that's why 'constant' term doesn't fits there, because
> there's
> > so many confusion about it. what are the constant in dynamic system,
> after
> > all?
>
>
--
Best regards,
Igor Stasenko.
Re: [Pharo-dev] memoized vs once
On 27 January 2017 at 01:30, Ben Coman <b...@openinworld.com> wrote:
> On Fri, Jan 27, 2017 at 6:02 AM, stepharong <stephar...@free.fr> wrote:
> > On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann <asta...@gmx.de>
> wrote:
> >
> >> stepharong wrote:
> >>>
> >>> can we rename this selector?
> >>> asMethodConst should be at least be renamed to asConstantMethod
> >>
> >>
> >> When you use "as {something}" then "something" depicts the result of the
> >> conversion message sent to an object.
> >>
> >> Like in #asNumber or #asString which shows to what the receiver will be
> >> converted.
> >
> >
> > Yes I thought that it was doing that.
> >>
> >>
> >>
> >> My understanding is that in the case discussed the receiver object is
> >> NOT converted to a constant unchangeable method, so #asConstantMethod
> >> would
> >> not fit as a selector.
> >>
> >> Instead it is sent to an object that afterwards is a constant within a
> >> method
> >> (so it will not be evaluated later at runtime again) so IMHO
> >> #asMethodConstant
> >> instead of #asMethodConst would be better.
> >
> >
> > I do not understand any of them.
>
> method constant = constant of a method
> constant method = method that does not change
>
> are you sure?
maybe it is
constant method = method that returns constant?
apparently, that's why 'constant' term doesn't fits there, because there's
so many confusion about it. what are the constant in dynamic system, after
all?
HTH, cheers -ben
>
>
--
Best regards,
Igor Stasenko.
Re: [Pharo-dev] athens dead code?
On 27 January 2017 at 00:06, stepharong <stephar...@free.fr> wrote: > > accept: aVisitor > ^ aVisitor lineSegment: self > accept: aVisitor > ^ aVisitor closeSegment: self > accept: aVisitor > ^ aVisitor moveSegment: self > > seems to invoke methods that do not exit > I check AthensLIneSegment is used so I do not understand why the methods > are broken. > > this is a part of visitor api for path segments. if you remove it, then users cannot use it for iterating trough path segments for converting them etc etc.. of course, it may be nit used by Athens itself.. but it doesn't means it is useless. > > -- > Using Opera's mail client: http://www.opera.com/mail/ > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] memoized vs once
On 27 January 2017 at 00:28, Chris Cunningham <cunningham...@gmail.com> wrote: > On Thu, Jan 26, 2017 at 2:02 PM, stepharong <stephar...@free.fr> wrote: > >> On Thu, 26 Jan 2017 20:38:49 +0100, Torsten Bergmann <asta...@gmx.de> >> wrote: >> >> ... >> >> >>> Instead it is sent to an object that afterwards is a constant within a >>> method >>> (so it will not be evaluated later at runtime again) so IMHO >>> #asMethodConstant >>> instead of #asMethodConst would be better. >>> >> >> I do not understand any of them. >> >> In other words, this is creating a constant inside the method > (#asMethodConstant) instead of making the method return a constant (which > would be your #asConstantMethod). > If I have that right. > In any case, not having the contracted 'Const' would be nice. > > ah.. that sounds similar to what i proposed for computed literals, that has been computed at compilation time and placed in method's literal frame, a simple catch by reserving special selector for it, i.e..: mymethod ^ (something that should be computed , and takes a loong time) asMethodLiteral but that, of course, won't work if you would want to cache results based on method's input parameters. > -cbc > >> -- >> Using Opera's mail client: http://www.opera.com/mail/ >> >> > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] memoized vs once
On 26 January 2017 at 02:10, p...@highoctane.be <p...@highoctane.be> wrote: > Ah ah :-D > > DynamicVariables are darker magic that this, right? > > you mean like those that seaside using? it lives as long as session lives, and tied to session you are working in.. in early versions of seaside they were using exceptions to access session storage.. quite ineffective.. but it works. for that purpose it is much better to use process-specific variables, that live and die together with process that hosts them.. but has significantly better access timings. and since seaside allocates a separate process per session, that's perfect fit. in any case, the concern about getting rid of volatile data is covered.. while with memoization, i don't see it. and that seems like a HUGE argument against using it, because it is more trouble in a long run than time saver when you just start using it everywhere. > Phil > > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] memoized vs once
On 26 January 2017 at 02:10, p...@highoctane.be <p...@highoctane.be> wrote: > Ah ah :-D > > In my example I want to be able to do the calls without caching or with > caching. Without for debugging because I amend the server side at times and > want always fresh data (yes, I could have a cache with TTL of about > nothing). > > and why that could be the problem in my example? you can always implement #at:ifAbsentPut: in the way you see fit.. cache disable. x := cache at: #something ifAbsentPut: [ blah ]. "always calculates, ignores the cache" cache enable. y := cache at: #something ifAbsentPut: [ blah ]. "prefers to calculate once, reuse result" you see what i mean? in any case you can easily avoid repeating same block twice.. that's for sure. > Memoization is useful for not having to write the caching thing all the > time. > > DynamicVariables are darker magic that this, right? > > Phil > > > On Thu, Jan 26, 2017 at 12:56 AM, Igor Stasenko <siguc...@gmail.com> > wrote: > >> Because caching are always comes with concerns, like when/where do we >> want to drop cached results and recalculate them, if needed.. >> With memoization it seems like there's simply no such concern at all.. >> meaning that cached data will live forever since created once.. which is >> never good >> for dynamic system.. because i spent significant portion of my smalltalk >> life hunting for leaks and immortal references that you cannot get rid of, >> because some guy forgot to provide a nice and easy interface or api to >> get rid of volatile data.. like open files or socket connections, session >> etc etc.. >> and now.. let us welcome.. memoization. :) >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] memoized vs once
Because caching are always comes with concerns, like when/where do we want to drop cached results and recalculate them, if needed.. With memoization it seems like there's simply no such concern at all.. meaning that cached data will live forever since created once.. which is never good for dynamic system.. because i spent significant portion of my smalltalk life hunting for leaks and immortal references that you cannot get rid of, because some guy forgot to provide a nice and easy interface or api to get rid of volatile data.. like open files or socket connections, session etc etc.. and now.. let us welcome.. memoization. :) -- Best regards, Igor Stasenko.
Re: [Pharo-dev] memoized vs once
On 26 January 2017 at 01:40, p...@highoctane.be <p...@highoctane.be> wrote: > Yeah, I get you 100%. > > I wanted to be able to cache or not and have this transparent. > > Memoization in its current form in Pharo is not like I would like to have > it. > > As for the repeating block, I was asking to how you would avoid repeating > in the given code structure. > You asking me rewrite it for your example? unless i missing something (not)obvious here, it can look like this: getIssueCreateMeta "Retrieves the metadata for all types of issues. Fields are expanded" ^ self cache at: #issueCreateMeta ifAbsentPut: [ self getIssueCreateMetaWithExpandKeys: true ] Btw, it is a good question, what are the difference between caching and memoization, besides that google underlines 'memoization' word with thin red curly line while i typing? :) -- Best regards, Igor Stasenko.
Re: [Pharo-dev] memoized vs once
On 26 January 2017 at 01:33, p...@highoctane.be <p...@highoctane.be> wrote: > self memoize: #methodThatDoesSomethingLong:. > > would automatically store parameters values as cache keys. No matter how > many such parms. > > No need to have blocks or anything,operations are memoized. > We use blocks for lack of a better way right now I guess. > > Phil > > well, that's something i calling 'caching'.. because if you cashing many results, depending on input data, then it is better to call caching.. but in original example, there's noting like this.. it is just block without arguments.. so, what you going to use as keys for caching evaluation of such block, how do you identify what value(s) are inputs for such block and what not? -- Best regards, Igor Stasenko.
Re: [Pharo-dev] memoized vs once
On 26 January 2017 at 01:23, p...@highoctane.be <p...@highoctane.be> wrote: > Nothing new, that's the term. > > Memoization: After computing a solution to a subproblem, store it in a > table. Subsequent calls check the table to avoid redoing work. > > https://en.wikipedia.org/wiki/Memoization > > http://www.cas.mcmaster.ca/~deza/6_Dynamic++.pdf > > http://wiki.tcl.tk/10779 > > I have been using the method for something else, caching costly REST calls. > > getIssueCreateMeta > "Retrieves the metadata for all types of issues. Fields are expanded" > ^ self isMemoizingMeta > ifTrue: [ ([ :ignored | self getIssueCreateMetaWithExpandKeys: true ] > memoizedUsing: self cache ) value: #issueCreateMeta ] > ifFalse: [ self getIssueCreateMetaWithExpandKeys: true ] > > > using: > > cache > ^ cache ifNil: [cache := LRUCache new maximumWeight: self > defaultCacheWeight ] > > It is nice to see the cache hit rate etc in the inspector. > > BTW I am interested to see how one coul dwrite the code above without > repeating the block. > Also, :ignored is not used by the method but is the cache key. > > well, for not repeating, its easy, for instance in NativeBoost i just used expressions like: getIssueCreateMeta ^ self cacheAt: somekey ifAbsentPut: [ some data ] which are self-explanatory (i hope) where somekey could be 'self' or whatever seem fit. as for the caching wihoout key, why not just store result of first evaluation and then use it directly anywhere else? why need to wrap it with block?? data := [some calculation ] value. self doSomethingWith: data. self doSomethingElseWith: data. self doSomethingElseElseWith: data. voila.. plain programming. Where does memoization need to be coined here? :) Phil > > On Wed, Jan 25, 2017 at 10:30 PM, Igor Stasenko <siguc...@gmail.com> > wrote: > >> #once can be interpreted as 'evaluate it once', >> >> but i don't like the #memoized .. it sounds painful to my ears. >> It sounds like something stinking smeared across my face.. and i always >> got stuck,confused and lost as the meaning of it always >> escaping my mind, since it naturally defends itself from any unpleasant >> thoughts. >> >> IMHO, maybe #once is not the best wording for what it does , but >> #memoizing... yuck.. pardon me. >> >> :) >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] memoized vs once
result := [ do something long or short or whatever] cached. On 26 January 2017 at 01:20, Igor Stasenko <siguc...@gmail.com> wrote: > > > On 26 January 2017 at 01:14, p...@highoctane.be <p...@highoctane.be> > wrote: > >> If one is doing any dynamic programming, the memoization term is pretty >> natural. >> >> for that purpose, i naturally using 'caching' wording. > > >> https://youtu.be/OQ5jsbhAv_M?t=3m11s >> >> Phil >> >> On Wed, Jan 25, 2017 at 10:30 PM, Igor Stasenko <siguc...@gmail.com> >> wrote: >> >>> #once can be interpreted as 'evaluate it once', >>> >>> but i don't like the #memoized .. it sounds painful to my ears. >>> It sounds like something stinking smeared across my face.. and i always >>> got stuck,confused and lost as the meaning of it always >>> escaping my mind, since it naturally defends itself from any unpleasant >>> thoughts. >>> >>> IMHO, maybe #once is not the best wording for what it does , but >>> #memoizing... yuck.. pardon me. >>> >>> :) >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] memoized vs once
On 26 January 2017 at 01:14, p...@highoctane.be <p...@highoctane.be> wrote: > If one is doing any dynamic programming, the memoization term is pretty > natural. > > for that purpose, i naturally using 'caching' wording. > https://youtu.be/OQ5jsbhAv_M?t=3m11s > > Phil > > On Wed, Jan 25, 2017 at 10:30 PM, Igor Stasenko <siguc...@gmail.com> > wrote: > >> #once can be interpreted as 'evaluate it once', >> >> but i don't like the #memoized .. it sounds painful to my ears. >> It sounds like something stinking smeared across my face.. and i always >> got stuck,confused and lost as the meaning of it always >> escaping my mind, since it naturally defends itself from any unpleasant >> thoughts. >> >> IMHO, maybe #once is not the best wording for what it does , but >> #memoizing... yuck.. pardon me. >> >> :) >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] memoized vs once
#once can be interpreted as 'evaluate it once', but i don't like the #memoized .. it sounds painful to my ears. It sounds like something stinking smeared across my face.. and i always got stuck,confused and lost as the meaning of it always escaping my mind, since it naturally defends itself from any unpleasant thoughts. IMHO, maybe #once is not the best wording for what it does , but #memoizing... yuck.. pardon me. :) -- Best regards, Igor Stasenko.
Re: [Pharo-dev] it's too quiet ... please ignore (except for stef:)
who's there? :) On 29 December 2016 at 21:31, Dimitris Chloupis <kilon.al...@gmail.com> wrote: > I still love to get in trouble though I suck at getting up early , even > for Santa. Morfeas gives me busy :D > > On Thu, 29 Dec 2016 at 21:04, Dale Henrichs <dale.henrichs@gemtalksystems. > com> wrote: > >> >> >> >> >> >> >> >> >> >> >> I always got in trouble on Christmas ... getting up too early:) >> >> >> >> >> >> >> >> On 12/29/16 11:00 AM, Dimitris Chloupis >> >> wrote: >> >> >> >> >> S we are waiting for Santa ;) >> >> >> >> >> On Thu, 29 Dec 2016 at 20:10, Dale Henrichs < >> dale.henri...@gemtalksystems.com> >> >> wrote: >> >> >> >> >> The list >> >> server is up so it's just quiet:) >> >> >> >> >> >> >> >> >> On 12/29/16 10:04 AM, Dale Henrichs wrote: >> >> >> > No messages on list since yesterday morning? >> >> >> > >> >> >> > Dale >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Happy overquote! :) -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Q: any work around ROS has been done on Pharo?
Hmm okay, i created own ros package and started an example nodelet that prints 'hello world' , when i push messages from outside by ros.. now the question is how i should gracefully stop these nodelets and let them unsubscribe/die gracefully.. because i now have 4 instances of ROSMaster in my image and all locked by waiting for some mutex/semaphores and telling them 'stop' waits forever and blocks everything.. How i can clean this up? -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Q: any work around ROS has been done on Pharo?
Cool, i installed it, and now i have some questions. What i should do in order to: - connect with ros master - get list of available topics - subscribe to a chosen topic - and finally receive some data from it On 25 December 2016 at 06:25, Igor Stasenko <siguc...@gmail.com> wrote: > > > On 24 December 2016 at 14:07, Johan Fabry <jfa...@dcc.uchile.cl> wrote: > >> Hi Igor, Alex, >> >> we are actually using PhaROS underneath, which was built by the guys at >> Douai (Luc, Noury, et.al.). They deserve all the ROS interfacing credit :-) >> See http://car.mines-douai.fr/2014/06/how-to-install-pharos/ >> >> >> Yeah.. i will no doubt check it.. once i get managed to establish > bullet-proof connection with our drone.. today i spent day hacking my > unix box to bring up connection automatically, > once i plug the modem.. > I just don't see how else i could use ROS :) The perspective of sitting in > python for it frightens me to deepest depths :) > > >> -- >> Does this mail seem too brief? Sorry for that, I don’t mean to be rude! >> Please see http://emailcharter.org . >> >> Johan Fabry - http://pleiad.cl/~jfabry >> PLEIAD and RyCh labs - Computer Science Department (DCC) - University >> of Chile >> >> > On 24 Dec 2016, at 07:49, Alexandre Bergel <alexandre.ber...@me.com> >> wrote: >> > >> > Hi Igor, >> > >> > Johan Fabry and his group have been working on a complete environment >> on top of ROS to steer robots. >> > https://pleiad.cl/research/software/lrp >> > >> > Cheers, >> > Alexandre >> > >> > >> >> On Dec 22, 2016, at 9:38 PM, Igor Stasenko <siguc...@gmail.com> wrote: >> >> >> >> Hi, >> >> >> >> i wonder, are there any projects to run/connect Pharo with ROS(robot >> operating system) >> >> i'm interested in any bits, starting from basic ones, >> >> since i'm gonna to work with it in closest future, so would be nice to >> use Pharo >> >> & stand on a shoulders of others, of course, to learn it fester and >> understand it better. >> >> >> >> -- >> >> Best regards, >> >> Igor Stasenko. >> > >> > -- >> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > Alexandre Bergel http://www.bergel.eu >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > >> > >> > >> > >> >> >> > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] How stable 64-bit VM?
ah, yeah, forgot to mention that i run it on ubuntu 16.04 On 25 December 2016 at 06:28, Igor Stasenko <siguc...@gmail.com> wrote: > Hi, > sorry for my ignorance, > i downloaded fresh build of 64-bit VM and has strange hiccups (crash on > downloading/installing a package)... > is it stable, or it is just me, too ignorant & stupid? > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.
[Pharo-dev] How stable 64-bit VM?
Hi, sorry for my ignorance, i downloaded fresh build of 64-bit VM and has strange hiccups (crash on downloading/installing a package)... is it stable, or it is just me, too ignorant & stupid? -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Q: any work around ROS has been done on Pharo?
On 24 December 2016 at 14:07, Johan Fabry <jfa...@dcc.uchile.cl> wrote: > Hi Igor, Alex, > > we are actually using PhaROS underneath, which was built by the guys at > Douai (Luc, Noury, et.al.). They deserve all the ROS interfacing credit :-) > See http://car.mines-douai.fr/2014/06/how-to-install-pharos/ > > > Yeah.. i will no doubt check it.. once i get managed to establish bullet-proof connection with our drone.. today i spent day hacking my unix box to bring up connection automatically, once i plug the modem.. I just don't see how else i could use ROS :) The perspective of sitting in python for it frightens me to deepest depths :) > -- > Does this mail seem too brief? Sorry for that, I don’t mean to be rude! > Please see http://emailcharter.org . > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD and RyCh labs - Computer Science Department (DCC) - University > of Chile > > > On 24 Dec 2016, at 07:49, Alexandre Bergel <alexandre.ber...@me.com> > wrote: > > > > Hi Igor, > > > > Johan Fabry and his group have been working on a complete environment on > top of ROS to steer robots. > > https://pleiad.cl/research/software/lrp > > > > Cheers, > > Alexandre > > > > > >> On Dec 22, 2016, at 9:38 PM, Igor Stasenko <siguc...@gmail.com> wrote: > >> > >> Hi, > >> > >> i wonder, are there any projects to run/connect Pharo with ROS(robot > operating system) > >> i'm interested in any bits, starting from basic ones, > >> since i'm gonna to work with it in closest future, so would be nice to > use Pharo > >> & stand on a shoulders of others, of course, to learn it fester and > understand it better. > >> > >> -- > >> Best regards, > >> Igor Stasenko. > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Q: any work around ROS has been done on Pharo?
Yes, i remember this.. But i never had a chance to look for details.. Would be nice to hear what is there, since i complete noob with ROS :) Is Noury & others reading this mailing list? I thought they are.. On 23 December 2016 at 17:15, stepharong <stephar...@free.fr> wrote: > Hi igor > > Pharos is developed at Ecole des Mines de Douai by Noury, Luc and Santiago > was working on it during 1,5 years. > Noury Bouraqadi <noury.bouraq...@mines-douai.fr> > Luc Fabresse <luc.fabre...@gmail.com> > > Stef > > On Thu, 22 Dec 2016 21:38:29 +0100, Igor Stasenko <siguc...@gmail.com> > wrote: > > Hi, > > i wonder, are there any projects to run/connect Pharo with ROS(robot > operating system) > i'm interested in any bits, starting from basic ones, > since i'm gonna to work with it in closest future, so would be nice to use > Pharo > & stand on a shoulders of others, of course, to learn it fester and > understand it better. > > -- > Best regards, > Igor Stasenko. > > > > > -- > Using Opera's mail client: http://www.opera.com/mail/ > -- Best regards, Igor Stasenko.
[Pharo-dev] Q: any work around ROS has been done on Pharo?
Hi, i wonder, are there any projects to run/connect Pharo with ROS(robot operating system) i'm interested in any bits, starting from basic ones, since i'm gonna to work with it in closest future, so would be nice to use Pharo & stand on a shoulders of others, of course, to learn it fester and understand it better. -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Pharo on Raspberry, how? Who?
On 22 December 2016 at 22:27, Sven Van Caekenberghe <s...@stfx.eu> wrote: > > > On 22 Dec 2016, at 21:13, Igor Stasenko <siguc...@gmail.com> wrote: > > > > > > > > On 22 December 2016 at 21:50, Sven Van Caekenberghe <s...@stfx.eu> > wrote: > > > > > On 22 Dec 2016, at 20:40, Igor Stasenko <siguc...@gmail.com> wrote: > > > > > > > > > so, as i understand VM comes by default with raspbian installation, or > what? > > > > yes, there is one included, it is not a Pharo one, for recent Pharo > images you need a very recent one. > > > > .. which can be dl/ed from... ? > > > > > and what are those: > > > https://bintray.com/estebanlm/pharo-vm/download_file?file_ > path=pharo-linux-ARMv6.0b8386a.zip > > > > > > ? > > > > that is a pharo one. > > > > hmm, you left me confused.. which one will work? > > the one in the link, or a newer one at the same place. > > > btw, do i need a specially prepared image? just asking in case if anyone > has one.. > > no, a standard 5.0 will do. > ookay... will try it tomorrow.. thanks, Sven, you are very helpful, as always! > > > -- > > Best regards, > > Igor Stasenko. > > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Pharo on Raspberry, how? Who?
On 22 December 2016 at 21:50, Sven Van Caekenberghe <s...@stfx.eu> wrote: > > > On 22 Dec 2016, at 20:40, Igor Stasenko <siguc...@gmail.com> wrote: > > > > > > so, as i understand VM comes by default with raspbian installation, or > what? > > yes, there is one included, it is not a Pharo one, for recent Pharo images > you need a very recent one. > > .. which can be dl/ed from... ? > > and what are those: > > https://bintray.com/estebanlm/pharo-vm/download_file?file_ > path=pharo-linux-ARMv6.0b8386a.zip > > > > ? > > that is a pharo one. > > hmm, you left me confused.. which one will work? btw, do i need a specially prepared image? just asking in case if anyone has one.. -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Pharo on Raspberry, how? Who?
so, as i understand VM comes by default with raspbian installation, or what? and what are those: https://bintray.com/estebanlm/pharo-vm/download_file?file_path=pharo-linux-ARMv6.0b8386a.zip ? -- Best regards, Igor Stasenko.
[Pharo-dev] Pharo on Raspberry, how? Who?
Hi there, i have this cute device on my hands, and wanna show my colleges how cool Pharo is.. i remember Pavel shown us once, that it works and possible, and i would like to try as well.. since i hate python, and i would much more prefer to run humane-friendly language, such as our beloved smalltalk rather than prehistoric-era scripting language :) -- Best regards, Igor Stasenko.
Re: [Pharo-dev] about syntaxError
and this works simply by knowing that primitive 19 always fails (this is guaranteed by VM itself). so when you run code naturally - the primitive fails, and so it runs the body of method. but when same method attempted to activate(simulate) via debugger - it doesn't runs a method body and doing something else, what exactly - look at debugger code, because i don't remember :). On 9 December 2016 at 02:00, Igor Stasenko <siguc...@gmail.com> wrote: > > On 9 December 2016 at 01:39, p...@highoctane.be <p...@highoctane.be> > wrote: > >> Nice to now understand how this debugger thing behaves. >> >> I have some issues when debugging tests GTDebugger in Pharo5 when there >> is a self halt in the test method. For some reason the step through looks >> like out of what with the actual thing to step through. >> >> How does that work? >> > > well, IIRC, when you stepping through, the debugger running a simulation > and detects that you trying to interrupt it > and since it is not a good idea to interrupt the debugger itself , else > you will need to open yet another debugger window, > showing where the simulation/exception handling was interrupted.. and so > you enter an endless recursive loop, > and as result won't be able to debug anything :) > > And this 'simulation guard' is serving to prohibit further processing in > such cases, or in certain cases, it simply ignores > it and pretends that it is done, suppressing actual code behavior, which > would be triggered, if it wouldn't run simulated by debugger. > > >> Phil >> >> > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] about syntaxError
On 9 December 2016 at 01:39, p...@highoctane.be <p...@highoctane.be> wrote: > Nice to now understand how this debugger thing behaves. > > I have some issues when debugging tests GTDebugger in Pharo5 when there is > a self halt in the test method. For some reason the step through looks like > out of what with the actual thing to step through. > > How does that work? > well, IIRC, when you stepping through, the debugger running a simulation and detects that you trying to interrupt it and since it is not a good idea to interrupt the debugger itself , else you will need to open yet another debugger window, showing where the simulation/exception handling was interrupted.. and so you enter an endless recursive loop, and as result won't be able to debug anything :) And this 'simulation guard' is serving to prohibit further processing in such cases, or in certain cases, it simply ignores it and pretends that it is done, suppressing actual code behavior, which would be triggered, if it wouldn't run simulated by debugger. > Phil > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] about syntaxError
and this: "Simulation guard" is a good indication of what's gone wrong.. you are basically attempting to debug a debugger, using the very same debugger and this primitive is used throughout the debugger code to guard against such cases. On 9 December 2016 at 01:06, Igor Stasenko <siguc...@gmail.com> wrote: > > > On 8 December 2016 at 22:56, stepharong <stephar...@free.fr> wrote: > >> Sorry igot but I do not understand what you are saying. >> Too tired. >> > > the exception handler if it runs in UI process does following: > - spawns new UI process, > suspending the old one, that caused exception, > then creates a debugger that showing where the original exception occur. > > but if you put halt somewhere in the middle of exception handler , you > will either create an endless loop (of attempting to bring debugger), > or, when you lucky, as in your case - it will show you debugger , where > you interrupted the exception handling, > but not the original exception. > > >> >> coz u putting exception inside an exception handler.. >> yo gawd, so you like exceptions? >> lets put an exception inside your exception, so it will be thrown while >> it thrown >> :)) >> (i hope everyone knows this reference :) >> >> >> On 8 December 2016 at 22:07, stepharong <stephar...@free.fr> wrote: >> >>> I tried to fix the extract method refactoring that seems broken when >>> extracting class or variables. >>> And I wanted to understand if I can get a debugger stack instead of this >>> useless Syntax Error: window. >>> Now I cannot find reference to SyntaxErrorDebugger. >>> still putting a break point in >>> >>> buildMorphicViewOn: aSyntaxError >>> "Answer an Morphic view on the given SyntaxError." >>> >>> | window | >>> self halt. >>> >>> bring a debugger but with a cut stack >>> >>> open: aSyntaxError >>> "Answer a standard system view whose model is an instance of me." >>> >>> "Simulation guard" >>> | process | >>> process := Processor activeProcess. >>> UIManager default spawnNewProcessIfThisIsUI: process. >>> UIManager default defer: [ >>> self buildMorphicViewOn: aSyntaxError. >>> ]. >>> ^ process suspend >>> >>> so it does not really help to understand the syntax error. >>> I do not get why this is so opaque. >>> >>> Stef >>> >>> >>> -- >>> Using Opera's mail client: http://www.opera.com/mail/ >>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> >> >> >> -- >> Using Opera's mail client: http://www.opera.com/mail/ >> > > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] about syntaxError
coz u putting exception inside an exception handler.. yo gawd, so you like exceptions? lets put an exception inside your exception, so it will be thrown while it thrown :)) (i hope everyone knows this reference :) On 8 December 2016 at 22:07, stepharong <stephar...@free.fr> wrote: > I tried to fix the extract method refactoring that seems broken when > extracting class or variables. > And I wanted to understand if I can get a debugger stack instead of this > useless Syntax Error: window. > Now I cannot find reference to SyntaxErrorDebugger. > still putting a break point in > > buildMorphicViewOn: aSyntaxError > "Answer an Morphic view on the given SyntaxError." > > | window | > self halt. > > bring a debugger but with a cut stack > > open: aSyntaxError > "Answer a standard system view whose model is an instance of me." > > "Simulation guard" > | process | > process := Processor activeProcess. > UIManager default spawnNewProcessIfThisIsUI: process. > UIManager default defer: [ > self buildMorphicViewOn: aSyntaxError. > ]. > ^ process suspend > > so it does not really help to understand the syntax error. > I do not get why this is so opaque. > > Stef > > > -- > Using Opera's mail client: http://www.opera.com/mail/ > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Drastically improving the messageNotUnderstood title
not sure.. i envision something like that: https://cdn.meme.am/instances/500x/66976516.jpg -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Running on Ubuntu?
On 24 November 2016 at 04:43, Chris Muller <asquea...@gmail.com> wrote: > Hey Igor, I was just messing around with this the other day; Levente > had the tersest incantation which worked on my fresh 14.04.4 install: > > sudo dpkg --add-architecture i386 > sudo apt-get update > sudo apt-get install libuuid1:i386 libglu1-mesa:i386 libsm6:i386 > > (Documented at http://wiki.squeak.org/squeak/6134). > > yeah... if its fresh.. but i guess my problem was that there was something installed, that were blocking clean installation of above libs due to conflicting dependencies. anyways, this is not critical for my current needs. Thanks for attention. > On Tue, Nov 22, 2016 at 10:46 AM, Igor Stasenko <siguc...@gmail.com> > wrote: > > > > > > On 22 November 2016 at 16:50, Sven Van Caekenberghe <s...@stfx.eu> > wrote: > >> > >> Igor, > >> > >> For future reference, > >> > >> > On 22 Nov 2016, at 11:17, Sven Van Caekenberghe <s...@stfx.eu> wrote: > >> > > >> > (this is what I use for headless) > >> > > >> > sudo dpkg --add-architecture i386 > >> > sudo apt-get update > >> > sudo apt-get install libc6:i386 > >> > sudo apt-get install libssl1.0.0:i386 > >> > sudo apt-get install libfreetype6:i386 > >> > >> On a fresh Ubuntu 16.04.1 LTS 64-bit I did the above > >> > >> > (you might need more for full UI) > >> > >> And then just one other install > >> > >> sudo apt-get install libgl1-mesa-glx:i386 > >> > >> which installed lots of dependencies. > >> > >> After that I was able to run the download > >> > >> get.pharo.org/60+vm > >> > >> in UI mode (using pharo-ui). > >> > >> Sven > >> > > ohh.. wait 6.0 is on the sight.. and i was mangling with 5.0.. > > yeah, that explains why it needs 32-bit libs and all that mess :) > > > > > > -- > > Best regards, > > Igor Stasenko. > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit
On 23 November 2016 at 12:41, p...@highoctane.be <p...@highoctane.be> wrote: > > > On Wed, Nov 23, 2016 at 10:51 AM, Igor Stasenko <siguc...@gmail.com> > wrote: > >> >> >> On 23 November 2016 at 10:50, p...@highoctane.be <p...@highoctane.be> >> wrote: >> >>> >>> >>> On Wed, Nov 23, 2016 at 12:53 AM, Eliot Miranda <eliot.mira...@gmail.com >>> > wrote: >>> >>>> >>>> >>>> On Tue, Nov 22, 2016 at 10:26 AM, Sven Van Caekenberghe <s...@stfx.eu> >>>> wrote: >>>> >>>>> >>>>> > On 22 Nov 2016, at 19:16, p...@highoctane.be wrote: >>>>> > >>>>> > >>>>> > >>>>> > On Tue, Nov 22, 2016 at 5:57 PM, Igor Stasenko <siguc...@gmail.com> >>>>> wrote: >>>>> > >>>>> > >>>>> > On 15 November 2016 at 02:18, Eliot Miranda <eliot.mira...@gmail.com> >>>>> wrote: >>>>> > Hi Phil, >>>>> > >>>>> > On Thu, Nov 10, 2016 at 2:19 AM, p...@highoctane.be < >>>>> p...@highoctane.be> wrote: >>>>> > >>>>> > >>>>> > On Thu, Nov 10, 2016 at 10:31 AM, Denis Kudriashov < >>>>> dionisi...@gmail.com> wrote: >>>>> > >>>>> > 2016-11-10 9:49 GMT+01:00 p...@highoctane.be <p...@highoctane.be>: >>>>> > Ah, but then it may be more interesting to have a data image (maybe >>>>> a lot of these) and a front end image. >>>>> > >>>>> > Isn't Seamless something that could help us here? No need to bring >>>>> the data back, just manipulate it through proxies. >>>>> > >>>>> > Problem that server image will anyway perform GC. And it will be >>>>> slow if server image is big which will stop all world. >>>>> > >>>>> > What if we asked it to not do any GC at all? Like if we have tons of >>>>> RAM, why bother? Especially if what it is used to is to keep datasets: >>>>> load >>>>> them, save image to disk. When needed trash the loaded stuff and reload >>>>> from zero. >>>>> > >>>>> > Basically that is what happens with Spark. >>>>> > >>>>> > http://sujee.net/2015/01/22/understanding-spark-caching/#.WC >>>>> RIgy0rKpo >>>>> > https://0x0fff.com/spark-misconceptions/ >>>>> > >>>>> > While global GC may not be useful for big-data scavenging probably >>>>> will be for any non-trivial query. But I think I see a misconception >>>>> here. The large RAM on a multiword machine would be divided up between >>>>> the >>>>> cores. It makes no sense to run a single Smalltalk across lots of cores >>>>> (we're a long way from having a thread-safe class library). It makes much >>>>> more sense to have one Smalltalk per core. So that brings the heap sizes >>>>> down and makes GC less scary. >>>>> > >>>>> > yep, that approach what we're tried in HydraVM >>>>> > >>>>> > >>>>> > and Tachyon/Alluxio is kind of solving this kind of issue (may be >>>>> nice to have that interacting with Pharo image). >>>>> http://www.alluxio.org/ This thing basically keeps stuff in memory in >>>>> case one needs to reuse the data between workload runs. >>>>> > >>>>> > Sure. We have all the facilities we need to do this. We can add >>>>> and remove code at runtime so we can keep live instances running, and send >>>>> the code to them along with the data we want them to crunch. >>>>> > >>>>> > >>>>> > Or have an object memory for work and one for datasets (first one >>>>> gets GC'd, the other one isn't). >>>>> > >>>>> > Or have policies which one can switch. There are quite a few levers >>>>> into the GC from the image and one can easily switch off global GC with >>>>> the >>>>> right levers. One doesn't need a VM that doesn't contain a GC. One needs >>>>> an image that is using the right policy. >>>>> > >>>>> > or just mark whole data (sub)graphs with some bit, telling
Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit
On 23 November 2016 at 10:50, p...@highoctane.be <p...@highoctane.be> wrote: > > > On Wed, Nov 23, 2016 at 12:53 AM, Eliot Miranda <eliot.mira...@gmail.com> > wrote: > >> >> >> On Tue, Nov 22, 2016 at 10:26 AM, Sven Van Caekenberghe <s...@stfx.eu> >> wrote: >> >>> >>> > On 22 Nov 2016, at 19:16, p...@highoctane.be wrote: >>> > >>> > >>> > >>> > On Tue, Nov 22, 2016 at 5:57 PM, Igor Stasenko <siguc...@gmail.com> >>> wrote: >>> > >>> > >>> > On 15 November 2016 at 02:18, Eliot Miranda <eliot.mira...@gmail.com> >>> wrote: >>> > Hi Phil, >>> > >>> > On Thu, Nov 10, 2016 at 2:19 AM, p...@highoctane.be < >>> p...@highoctane.be> wrote: >>> > >>> > >>> > On Thu, Nov 10, 2016 at 10:31 AM, Denis Kudriashov < >>> dionisi...@gmail.com> wrote: >>> > >>> > 2016-11-10 9:49 GMT+01:00 p...@highoctane.be <p...@highoctane.be>: >>> > Ah, but then it may be more interesting to have a data image (maybe a >>> lot of these) and a front end image. >>> > >>> > Isn't Seamless something that could help us here? No need to bring the >>> data back, just manipulate it through proxies. >>> > >>> > Problem that server image will anyway perform GC. And it will be slow >>> if server image is big which will stop all world. >>> > >>> > What if we asked it to not do any GC at all? Like if we have tons of >>> RAM, why bother? Especially if what it is used to is to keep datasets: load >>> them, save image to disk. When needed trash the loaded stuff and reload >>> from zero. >>> > >>> > Basically that is what happens with Spark. >>> > >>> > http://sujee.net/2015/01/22/understanding-spark-caching/#.WCRIgy0rKpo >>> > https://0x0fff.com/spark-misconceptions/ >>> > >>> > While global GC may not be useful for big-data scavenging probably >>> will be for any non-trivial query. But I think I see a misconception >>> here. The large RAM on a multiword machine would be divided up between the >>> cores. It makes no sense to run a single Smalltalk across lots of cores >>> (we're a long way from having a thread-safe class library). It makes much >>> more sense to have one Smalltalk per core. So that brings the heap sizes >>> down and makes GC less scary. >>> > >>> > yep, that approach what we're tried in HydraVM >>> > >>> > >>> > and Tachyon/Alluxio is kind of solving this kind of issue (may be nice >>> to have that interacting with Pharo image). http://www.alluxio.org/ >>> This thing basically keeps stuff in memory in case one needs to reuse the >>> data between workload runs. >>> > >>> > Sure. We have all the facilities we need to do this. We can add and >>> remove code at runtime so we can keep live instances running, and send the >>> code to them along with the data we want them to crunch. >>> > >>> > >>> > Or have an object memory for work and one for datasets (first one gets >>> GC'd, the other one isn't). >>> > >>> > Or have policies which one can switch. There are quite a few levers >>> into the GC from the image and one can easily switch off global GC with the >>> right levers. One doesn't need a VM that doesn't contain a GC. One needs >>> an image that is using the right policy. >>> > >>> > or just mark whole data (sub)graphs with some bit, telling GC to skip >>> over this so it won't attempt to scan it treating them as always alive.. >>> > this is where we getting back to my idea of heap spaces, where you can >>> toss a subgraph into a special heap space that has such policy, that it is >>> never scanned/GCed automatically and can be triggered only manually or >>> something like that. >>> > >>> > Could be very useful for all kinds of large binary data, like videos >>> and sounds that we can load once and keep in the heap space. >>> > >>> > How hard would it be to get something like that? >>> >>> Large binary data poses no problem (as long as it's not a copying GC). >>> Since a binary blob contains no subpointers, no work needs to be done. A 1M >>> or 1G ByteArray is the same amount of GC work. >>> >> >> +1 >> > > Amen to that. But a dataset made of a gazillion of composites is not the > same, right? > > yep, as soon as you have references in your data, you add more work for GC > Phil > >> >> _,,,^..^,,,_ >> best, Eliot >> > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit
On 15 November 2016 at 02:18, Eliot Miranda <eliot.mira...@gmail.com> wrote: > Hi Phil, > > On Thu, Nov 10, 2016 at 2:19 AM, p...@highoctane.be <p...@highoctane.be> > wrote: > >> >> >> On Thu, Nov 10, 2016 at 10:31 AM, Denis Kudriashov <dionisi...@gmail.com> >> wrote: >> >>> >>> 2016-11-10 9:49 GMT+01:00 p...@highoctane.be <p...@highoctane.be>: >>> >>>> Ah, but then it may be more interesting to have a data image (maybe a >>>> lot of these) and a front end image. >>>> >>>> Isn't Seamless something that could help us here? No need to bring the >>>> data back, just manipulate it through proxies. >>>> >>> >>> Problem that server image will anyway perform GC. And it will be slow if >>> server image is big which will stop all world. >>> >> >> What if we asked it to not do any GC at all? Like if we have tons of RAM, >> why bother? Especially if what it is used to is to keep datasets: load >> them, save image to disk. When needed trash the loaded stuff and reload >> from zero. >> >> Basically that is what happens with Spark. >> >> http://sujee.net/2015/01/22/understanding-spark-caching/#.WCRIgy0rKpo >> https://0x0fff.com/spark-misconceptions/ >> > > While global GC may not be useful for big-data scavenging probably will be > for any non-trivial query. But I think I see a misconception here. The > large RAM on a multiword machine would be divided up between the cores. It > makes no sense to run a single Smalltalk across lots of cores (we're a long > way from having a thread-safe class library). It makes much more sense to > have one Smalltalk per core. So that brings the heap sizes down and makes > GC less scary. > yep, that approach what we're tried in HydraVM > > >> and Tachyon/Alluxio is kind of solving this kind of issue (may be nice to >> have that interacting with Pharo image). http://www.alluxio.org/ This >> thing basically keeps stuff in memory in case one needs to reuse the data >> between workload runs. >> > > Sure. We have all the facilities we need to do this. We can add and > remove code at runtime so we can keep live instances running, and send the > code to them along with the data we want them to crunch. > > >> >> Or have an object memory for work and one for datasets (first one gets >> GC'd, the other one isn't). >> > > Or have policies which one can switch. There are quite a few levers into > the GC from the image and one can easily switch off global GC with the > right levers. One doesn't need a VM that doesn't contain a GC. One needs > an image that is using the right policy. > or just mark whole data (sub)graphs with some bit, telling GC to skip over this so it won't attempt to scan it treating them as always alive.. this is where we getting back to my idea of heap spaces, where you can toss a subgraph into a special heap space that has such policy, that it is never scanned/GCed automatically and can be triggered only manually or something like that. > > Phil >> > > _,,,^..^,,,_ > best, Eliot > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Running on Ubuntu?
On 22 November 2016 at 16:50, Sven Van Caekenberghe <s...@stfx.eu> wrote: > Igor, > > For future reference, > > > On 22 Nov 2016, at 11:17, Sven Van Caekenberghe <s...@stfx.eu> wrote: > > > > (this is what I use for headless) > > > > sudo dpkg --add-architecture i386 > > sudo apt-get update > > sudo apt-get install libc6:i386 > > sudo apt-get install libssl1.0.0:i386 > > sudo apt-get install libfreetype6:i386 > > On a fresh Ubuntu 16.04.1 LTS 64-bit I did the above > > > (you might need more for full UI) > > And then just one other install > > sudo apt-get install libgl1-mesa-glx:i386 > > which installed lots of dependencies. > > After that I was able to run the download > > get.pharo.org/60+vm > > in UI mode (using pharo-ui). > > Sven > > ohh.. wait 6.0 is on the sight.. and i was mangling with 5.0.. yeah, that explains why it needs 32-bit libs and all that mess :) -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Running on Ubuntu?
On 22 November 2016 at 16:24, Thierry Goubier <thierry.goub...@gmail.com> wrote: > Igor, > > I have this script: > > https://gist.github.com/ThierryGoubier/3dbef94a959f4f8acb19 > > Now, I would suggest, if you don't have any need FFI-related (no Athens, > Roassal, bloc, etc...), use the 64 bits version: runs without installing > anything on a large variety of Linuxes. > > nvm, it seems i installed it somehow: - installed aptitude - pressed something there on required lib and it done something (uninstalled shomething/shuffled something/installed something) and after that i were able to run apt get install libgl1-mesa-glx:i386 without problems :) > Thierry > > > 2016-11-22 15:00 GMT+01:00 Igor Stasenko <siguc...@gmail.com>: > >> >> >> On 22 November 2016 at 15:06, David T. Lewis <le...@mail.msen.com> wrote: >> >>> On Tue, Nov 22, 2016 at 12:19:30PM +0200, Igor Stasenko wrote: >>> > ldd vm-display-X11 >>> > linux-gate.so.1 => (0xf77fd000) >>> > libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7799000) >>> > libGL.so.1 => not found >>> > libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xf7664000) >>> > libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf74b5000) >>> > /lib/ld-linux.so.2 (0x5664e000) >>> > libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xf7493000) >>> > libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf748e000) >>> > libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xf748a000) >>> > libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xf7482000) >>> > >>> > >>> > seems like i have everyting already except libgl... >>> > any ideas what package providing it? >>> > >>> >>> After some trial and error, this is what I ended up installing on my >>> Ubuntu system: >>> >>> sudo apt-get install libgl1-mesa-dri-lts-utopic:i386 >>> sudo apt-get install libgl1-mesa-glx-lts-utopic:i386 >>> sudo apt-get install mesa-common-dev >>> >>> Dave >>> >> >> meh.. >> >> sudo apt-get install libgl1-mesa-dri-lts-utopic:i386 >> Reading package lists... Done >> Building dependency tree >> Reading state information... Done >> Some packages could not be installed. This may mean that you have >> requested an impossible situation or if you are using the unstable >> distribution that some required packages have not yet been created >> or been moved out of Incoming. >> The following information may help to resolve the situation: >> >> The following packages have unmet dependencies: >> qtdeclarative5-qtfeedback-plugin : Depends: libqt5feedback5 but it is >> not going to be installed >> unity-control-center : Depends: libcheese-gtk23 (>= 3.4.0) but it is not >> going to be installed >> Depends: libcheese7 (>= 3.0.1) but it is not >> going to be installed >> E: Error, pkgProblemResolver::Resolve generated breaks, this may be >> caused by held packages. >> >> :( >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Running on Ubuntu?
VM now runs, thanks everyone for your attention.. i wish it would install (or report missing requirements) correctly by itself On 22 November 2016 at 16:30, Igor Stasenko <siguc...@gmail.com> wrote: > > > On 22 November 2016 at 16:24, Thierry Goubier <thierry.goub...@gmail.com> > wrote: > >> Igor, >> >> I have this script: >> >> https://gist.github.com/ThierryGoubier/3dbef94a959f4f8acb19 >> >> Now, I would suggest, if you don't have any need FFI-related (no Athens, >> Roassal, bloc, etc...), use the 64 bits version: runs without installing >> anything on a large variety of Linuxes. >> >> > nvm, it seems i installed it somehow: > - installed aptitude > - pressed something there on required lib and it done something > (uninstalled shomething/shuffled something/installed something) > and after that i were able to run > apt get install libgl1-mesa-glx:i386 > without problems > :) > > >> Thierry >> >> >> 2016-11-22 15:00 GMT+01:00 Igor Stasenko <siguc...@gmail.com>: >> >>> >>> >>> On 22 November 2016 at 15:06, David T. Lewis <le...@mail.msen.com> >>> wrote: >>> >>>> On Tue, Nov 22, 2016 at 12:19:30PM +0200, Igor Stasenko wrote: >>>> > ldd vm-display-X11 >>>> > linux-gate.so.1 => (0xf77fd000) >>>> > libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7799000) >>>> > libGL.so.1 => not found >>>> > libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xf7664000) >>>> > libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf74b5000) >>>> > /lib/ld-linux.so.2 (0x5664e000) >>>> > libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xf7493000) >>>> > libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf748e000) >>>> > libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xf748a000) >>>> > libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xf7482000) >>>> > >>>> > >>>> > seems like i have everyting already except libgl... >>>> > any ideas what package providing it? >>>> > >>>> >>>> After some trial and error, this is what I ended up installing on my >>>> Ubuntu system: >>>> >>>> sudo apt-get install libgl1-mesa-dri-lts-utopic:i386 >>>> sudo apt-get install libgl1-mesa-glx-lts-utopic:i386 >>>> sudo apt-get install mesa-common-dev >>>> >>>> Dave >>>> >>> >>> meh.. >>> >>> sudo apt-get install libgl1-mesa-dri-lts-utopic:i386 >>> Reading package lists... Done >>> Building dependency tree >>> Reading state information... Done >>> Some packages could not be installed. This may mean that you have >>> requested an impossible situation or if you are using the unstable >>> distribution that some required packages have not yet been created >>> or been moved out of Incoming. >>> The following information may help to resolve the situation: >>> >>> The following packages have unmet dependencies: >>> qtdeclarative5-qtfeedback-plugin : Depends: libqt5feedback5 but it is >>> not going to be installed >>> unity-control-center : Depends: libcheese-gtk23 (>= 3.4.0) but it is >>> not going to be installed >>> Depends: libcheese7 (>= 3.0.1) but it is not >>> going to be installed >>> E: Error, pkgProblemResolver::Resolve generated breaks, this may be >>> caused by held packages. >>> >>> :( >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Running on Ubuntu?
On 22 November 2016 at 15:06, David T. Lewis <le...@mail.msen.com> wrote: > On Tue, Nov 22, 2016 at 12:19:30PM +0200, Igor Stasenko wrote: > > ldd vm-display-X11 > > linux-gate.so.1 => (0xf77fd000) > > libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7799000) > > libGL.so.1 => not found > > libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xf7664000) > > libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf74b5000) > > /lib/ld-linux.so.2 (0x5664e000) > > libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xf7493000) > > libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf748e000) > > libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xf748a000) > > libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xf7482000) > > > > > > seems like i have everyting already except libgl... > > any ideas what package providing it? > > > > After some trial and error, this is what I ended up installing on my > Ubuntu system: > > sudo apt-get install libgl1-mesa-dri-lts-utopic:i386 > sudo apt-get install libgl1-mesa-glx-lts-utopic:i386 > sudo apt-get install mesa-common-dev > > Dave > meh.. sudo apt-get install libgl1-mesa-dri-lts-utopic:i386 Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: qtdeclarative5-qtfeedback-plugin : Depends: libqt5feedback5 but it is not going to be installed unity-control-center : Depends: libcheese-gtk23 (>= 3.4.0) but it is not going to be installed Depends: libcheese7 (>= 3.0.1) but it is not going to be installed E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages. :( -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Running on Ubuntu?
uname -a Linux CI-Host 4.2.0-42-generic #49~14.04.1-Ubuntu SMP Wed Jun 29 20:22:11 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux pharo - from get.pharo.org bash script. & from http://pharo.org/download but the both behave the same. On 22 November 2016 at 12:46, Sven Van Caekenberghe <s...@stfx.eu> wrote: > Igor, > > Give us some more details > > - Ubuntu version > - Pharo version > - URL you used to download the VM > > Sven > > > On 22 Nov 2016, at 11:22, Igor Stasenko <siguc...@gmail.com> wrote: > > > > > > > > On 22 November 2016 at 12:17, Sven Van Caekenberghe <s...@stfx.eu> > wrote: > > (this is what I use for headless) > > > > sudo dpkg --add-architecture i386 > > sudo apt-get update > > sudo apt-get install libc6:i386 > > sudo apt-get install libssl1.0.0:i386 > > sudo apt-get install libfreetype6:i386 > > > > ==>>> 0 upgraded, 0 newly installed, 0 to remove and 11 not upgraded. > > > > it seems like everything of above already installed on my box. > > > > (you might need more for full UI) > > > > with ldd you can find unresolved dynamic libs > > > > > On 22 Nov 2016, at 11:13, Igor Stasenko <siguc...@gmail.com> wrote: > > > > > > > > > > > > On 22 November 2016 at 12:11, Nicolai Hess <nicolaih...@gmail.com> > wrote: > > > > > > > > > 2016-11-22 11:07 GMT+01:00 Igor Stasenko <siguc...@gmail.com>: > > > Hey guys, > > > > > > just wanted to show others our cool stuff.. but faced strange problem: > > > > > > ~/projects/pharo$ ./pharo-vm/pharo pharo.image > > > could not find display driver vm-display-X11; either: > > > - check that /home/sig/projects/pharo/pharo-vm//vm-display-X11.so > exists, or > > > - use the '-plugins ' option to tell me where it is, or > > > - remove DISPLAY from your environment. > > > Aborted (core dumped) > > > > > > i tried to download manually, tried to use command-line install script > .. but same result: > > > - it doesn't seem to want to pick up the x11 driver and so, fails to > start.. > > > needless to say, that driver exists, lies there right at the location > of vm binary etc etc yadda yadda.. > > > > > > anyone knows what going on? > > > > > > > > > Ubuntu 64 bit Linux ? If so, you need to make sure to have all 32Bit > libs. > > > > > > aha.. can you remind me how to install them quickly? > > > > > > > > > -- > > > Best regards, > > > Igor Stasenko. > > > > > > > > > > > > > > > -- > > > Best regards, > > > Igor Stasenko. > > > > > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Running on Ubuntu?
On 22 November 2016 at 12:17, Sven Van Caekenberghe <s...@stfx.eu> wrote: > (this is what I use for headless) > > sudo dpkg --add-architecture i386 > sudo apt-get update > sudo apt-get install libc6:i386 > sudo apt-get install libssl1.0.0:i386 > sudo apt-get install libfreetype6:i386 > > ==>>> 0 upgraded, 0 newly installed, 0 to remove and 11 not upgraded. it seems like everything of above already installed on my box. > (you might need more for full UI) > > with ldd you can find unresolved dynamic libs > > > On 22 Nov 2016, at 11:13, Igor Stasenko <siguc...@gmail.com> wrote: > > > > > > > > On 22 November 2016 at 12:11, Nicolai Hess <nicolaih...@gmail.com> > wrote: > > > > > > 2016-11-22 11:07 GMT+01:00 Igor Stasenko <siguc...@gmail.com>: > > Hey guys, > > > > just wanted to show others our cool stuff.. but faced strange problem: > > > > ~/projects/pharo$ ./pharo-vm/pharo pharo.image > > could not find display driver vm-display-X11; either: > > - check that /home/sig/projects/pharo/pharo-vm//vm-display-X11.so > exists, or > > - use the '-plugins ' option to tell me where it is, or > > - remove DISPLAY from your environment. > > Aborted (core dumped) > > > > i tried to download manually, tried to use command-line install script > .. but same result: > > - it doesn't seem to want to pick up the x11 driver and so, fails to > start.. > > needless to say, that driver exists, lies there right at the location of > vm binary etc etc yadda yadda.. > > > > anyone knows what going on? > > > > > > Ubuntu 64 bit Linux ? If so, you need to make sure to have all 32Bit > libs. > > > > aha.. can you remind me how to install them quickly? > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Running on Ubuntu?
ldd vm-display-X11 linux-gate.so.1 => (0xf77fd000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf7799000) libGL.so.1 => not found libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xf7664000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf74b5000) /lib/ld-linux.so.2 (0x5664e000) libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xf7493000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf748e000) libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xf748a000) libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xf7482000) seems like i have everyting already except libgl... any ideas what package providing it? On 22 November 2016 at 12:17, Sven Van Caekenberghe <s...@stfx.eu> wrote: > (this is what I use for headless) > > sudo dpkg --add-architecture i386 > sudo apt-get update > sudo apt-get install libc6:i386 > sudo apt-get install libssl1.0.0:i386 > sudo apt-get install libfreetype6:i386 > > (you might need more for full UI) > > with ldd you can find unresolved dynamic libs > > > On 22 Nov 2016, at 11:13, Igor Stasenko <siguc...@gmail.com> wrote: > > > > > > > > On 22 November 2016 at 12:11, Nicolai Hess <nicolaih...@gmail.com> > wrote: > > > > > > 2016-11-22 11:07 GMT+01:00 Igor Stasenko <siguc...@gmail.com>: > > Hey guys, > > > > just wanted to show others our cool stuff.. but faced strange problem: > > > > ~/projects/pharo$ ./pharo-vm/pharo pharo.image > > could not find display driver vm-display-X11; either: > > - check that /home/sig/projects/pharo/pharo-vm//vm-display-X11.so > exists, or > > - use the '-plugins ' option to tell me where it is, or > > - remove DISPLAY from your environment. > > Aborted (core dumped) > > > > i tried to download manually, tried to use command-line install script > .. but same result: > > - it doesn't seem to want to pick up the x11 driver and so, fails to > start.. > > needless to say, that driver exists, lies there right at the location of > vm binary etc etc yadda yadda.. > > > > anyone knows what going on? > > > > > > Ubuntu 64 bit Linux ? If so, you need to make sure to have all 32Bit > libs. > > > > aha.. can you remind me how to install them quickly? > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Running on Ubuntu?
On 22 November 2016 at 12:11, Nicolai Hess <nicolaih...@gmail.com> wrote: > > > 2016-11-22 11:07 GMT+01:00 Igor Stasenko <siguc...@gmail.com>: > >> Hey guys, >> >> just wanted to show others our cool stuff.. but faced strange problem: >> >> ~/projects/pharo$ ./pharo-vm/pharo pharo.image >> could not find display driver vm-display-X11; either: >> - check that /home/sig/projects/pharo/pharo-vm//vm-display-X11.so >> exists, or >> - use the '-plugins ' option to tell me where it is, or >> - remove DISPLAY from your environment. >> Aborted (core dumped) >> >> i tried to download manually, tried to use command-line install script .. >> but same result: >> - it doesn't seem to want to pick up the x11 driver and so, fails to >> start.. >> needless to say, that driver exists, lies there right at the location of >> vm binary etc etc yadda yadda.. >> >> anyone knows what going on? >> >> > Ubuntu 64 bit Linux ? If so, you need to make sure to have all 32Bit libs. > aha.. can you remind me how to install them quickly? > > >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.
[Pharo-dev] Running on Ubuntu?
Hey guys, just wanted to show others our cool stuff.. but faced strange problem: ~/projects/pharo$ ./pharo-vm/pharo pharo.image could not find display driver vm-display-X11; either: - check that /home/sig/projects/pharo/pharo-vm//vm-display-X11.so exists, or - use the '-plugins ' option to tell me where it is, or - remove DISPLAY from your environment. Aborted (core dumped) i tried to download manually, tried to use command-line install script .. but same result: - it doesn't seem to want to pick up the x11 driver and so, fails to start.. needless to say, that driver exists, lies there right at the location of vm binary etc etc yadda yadda.. anyone knows what going on? -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit
On 10 November 2016 at 19:58, Stephan Eggermont <step...@stack.nl> wrote: > Igor wrote: > >Now i hope at the end of the day, > >the guys who doing data mining/statistical > >analysis will finally shut up and happily > >be able to work with more bloat without > >need of learning a ways to properly > >manage memory & resources, and > >implement them finally. > > The actual problem is of course having to work with all that data before > you understand the structure. Or highly interconnected structures with > unpredictable access patterns. Partial graphs are nice, once you understand > how to partition. Needing to understand how to partition first is a > dependency I'd rather avoid. > > No, no, no! This is simply not true. It is you, who writes the code that generates a lot of statistical data/analysis data, and its output is fairly predictable.. else you are not collecting any data, but just a random noise, isn't? Those graphs are far from being unpredictable, because they are product of a software you wrote. Its not unpredictable, unless you claim that code you write is unpredictable, then i wonder, what are you doing in a field of data analysis, if you admit that your data is nothing but just a dice roll? If you cannot tame & reason about the complexity of own code, then maybe better to change occupation and go work in casino? :) I mean, Doru is light years ahead of me and many others in field of data analysis.. so what i can advise to him on his playground? You absolutely right, that the most hardest part, you identified, is find the way how you dissect the graph data on smaller chunks. And storing such dissected graph in chunks on a hard drive outside of image and loading in case of need, is just nothing compared to the first part. And if Doru can't handle this, then who else can? Me? I have nothing comparing to his experience in that field. I had very little/occasional experience in my career where i had to deal with such domain. Cmon.. > >Because even if you can fit all data in > >memory, consider how much time it takes > >for GC to scan 4+ Gb of memory, > > That's often not what is happening. The large data is mostly static, so > gets moved out of new space very quickly. Otherwise working with large data > quickly becomes annoying indeed. I fully agree with you on that. > > Stephan > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit
On 10 November 2016 at 18:57, Tudor Girba <tu...@tudorgirba.com> wrote: > Hi Igor, > > I see you are still having fun :). I am not sure what you are arguing > about, but it does not seem to be much related to what I said. > > It is not fun, seeing that after years since we discussed this problem, and i shared my view on it, nothing changed. I really wish that problem be lifted from your eyesight. But your rhetoric tells me that you prefer to sit and wait instead of solving it. But feel free to tell me, if i am wrong. > And again, I would be very happy to work with you on something concrete. > Just let me know if this is of interest and perhaps we can channel the > energy on solutions rather than on discussions like this. > > Why bother? Lets wait till be will have desktops with 1TB of RAM :) Ohh. sorry. Yeah, unfortunately i don't have much free time right now to dedicate to Pharo. But who knows, it may change. As you can see i keep coming, because smalltalk is not something you can forget after you learned it :) Please, don't take my tone too close. Its my frustration takes offensive forms. My frustration, that i assuming that you can help youself, because your problem is not that hard to solve. But instead, you prefer to rely on somebody else's effort(s). Arrhgghhh!! :) Cheers, > Doru > > > > > > -- > > Best regards, > > Igor Stasenko. > > -- > www.tudorgirba.com > www.feenk.com > > "From an abstract enough point of view, any two things are similar." > > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit
On 10 November 2016 at 18:41, Sven Van Caekenberghe <s...@stfx.eu> wrote: > > > On 10 Nov 2016, at 17:35, Aliaksei Syrel <alex.sy...@gmail.com> wrote: > > > > > The speed of GC will always be in linear dependency from the size of > governed memory. > > > > Asymptotic complexity of GC is O(N), where N is heap size - amount of > objects, not memory size. > > Even that is not necessarily true, Generational Garbage collection and > other tricks can avoid a full heap GC for a long time, even (or especially) > under memory allocation stress. > That's why it asymptotic.. Still more objects => more memory.. O(N) => O(K).. so my statement holds true. And all of the tricks is a puny attempts to workaround that , all those generational, multi-generational, permanent space etc etc. It does helps, of course, but not solves the problem. Since you can always invent a real-world scenario where you can put it on knees and so, that it from 'asymptotic' becomes quite 'symptotic'.. so, all those elaborations does not dismiss my argument, especially when we're talking about large data. When it comes about BIG data - manual data/resource management is the way to go. The rest is handwaving and self-delugion :) > > Apart from that, of course we have to write the most resource efficient > code that we can ! > > > I agree, however, that it's not good to create a lot of short living > objects. That is why there are many practices how to overcome this problem. > For example Object Pool can be nice example. > > > > Nevertheless I can imagine many usecasses when breaking 4GB limit is > useful. For example double buffering during rendering process. 1 pixel > takes 32bit of memory => 8k image (near future displays) would take 126Mb > of memory. Double buffering would be useful for Roassal (huge zoomed out > visualization). > > > > Storing 126Mb array object takes a lot of memory but does not influence > on GC performance since it is just one object on the heap. > > > > Cheers > > Alex > > > > > > On Nov 10, 2016 5:02 PM, "Igor Stasenko" <siguc...@gmail.com> wrote: > > > > > > On 10 November 2016 at 11:42, Tudor Girba <tu...@tudorgirba.com> wrote: > > Hi Igor, > > > > I am happy to see you getting active again. The next step is to commit > code at the rate you reply emails. I’d be even happier :). > > > > To address your point, of course it certainly would be great to have > more people work on automated support for swapping data in and out of the > image. That was the original idea behind the Fuel work. I have seen a > couple of cases on the mailing lists where people are actually using Fuel > for caching purposes. I have done this a couple of times, too. But, at this > point these are dedicated solutions and would be interesting to see it > expand further. > > > > However, your assumption is that the best design is one that deals with > small chunks of data at a time. This made a lot of sense when memory was > expensive and small. But, these days the cost is going down very rapidly, > and sizes of 128+ GB of RAM is nowadays quite cheap, and there are strong > signs of super large non-volatile memories become increasingly accessible. > The software design should take advantage of what hardware offers, so it is > not unreasonable to want to have a GC that can deal with large size. > > > > The speed of GC will always be in linear dependency from the size of > governed memory. Yes, yes.. super fast and super clever, made by some > wizard.. but still same dependency. > > So, it will be always in your interest to keep memory footprint as small > as possible. PERIOD. > > > > We should always challenge the assumptions behind our designs, because > the world keeps changing and we risk becoming irrelevant, a syndrome that > is not foreign to Smalltalk aficionados. > > > > > > What you saying is just: okay, we have a problem here, we hit a wall.. > But we don't look for solutions! Instead let us sit and wait till someone > else will be so generous to help with it. > > WOW, what a brilliant strategy!! > > So, you putting fate of your project(s) into hands of 3-rd party, which > > a) maybe , only maybe will work to solve your problem in next 10 years > > b) may decide it not worth effort right now(never) and focus on > something else, because they have own priorities after all > > > > Are you serious? > > "Our furniture don't fits in modern truck(s), so let us wait will > industry invent bigger trucks, build larger roads and then we will move" > Hilarious! > > > > In that case, the problem that you arising is n
Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit
On 10 November 2016 at 11:42, Tudor Girba <tu...@tudorgirba.com> wrote: > Hi Igor, > > I am happy to see you getting active again. The next step is to commit > code at the rate you reply emails. I’d be even happier :). > > To address your point, of course it certainly would be great to have more > people work on automated support for swapping data in and out of the image. > That was the original idea behind the Fuel work. I have seen a couple of > cases on the mailing lists where people are actually using Fuel for caching > purposes. I have done this a couple of times, too. But, at this point these > are dedicated solutions and would be interesting to see it expand further. > > However, your assumption is that the best design is one that deals with > small chunks of data at a time. This made a lot of sense when memory was > expensive and small. But, these days the cost is going down very rapidly, > and sizes of 128+ GB of RAM is nowadays quite cheap, and there are strong > signs of super large non-volatile memories become increasingly accessible. > The software design should take advantage of what hardware offers, so it is > not unreasonable to want to have a GC that can deal with large size. > > The speed of GC will always be in linear dependency from the size of governed memory. Yes, yes.. super fast and super clever, made by some wizard.. but still same dependency. So, it will be always in your interest to keep memory footprint as small as possible. PERIOD. > We should always challenge the assumptions behind our designs, because the > world keeps changing and we risk becoming irrelevant, a syndrome that is > not foreign to Smalltalk aficionados. > > What you saying is just: okay, we have a problem here, we hit a wall.. But we don't look for solutions! Instead let us sit and wait till someone else will be so generous to help with it. WOW, what a brilliant strategy!! So, you putting fate of your project(s) into hands of 3-rd party, which a) maybe , only maybe will work to solve your problem in next 10 years b) may decide it not worth effort right now(never) and focus on something else, because they have own priorities after all Are you serious? "Our furniture don't fits in modern truck(s), so let us wait will industry invent bigger trucks, build larger roads and then we will move" Hilarious! In that case, the problem that you arising is not that mission-critical to you, and thus making constant noise about your problem(s) is just what it is: a noise. Which returns us to my original mail with offensive tone. Cheers, > Doru > > > > -- > www.tudorgirba.com > www.feenk.com > > "Not knowing how to do something is not an argument for how it cannot be > done." > > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit
On 10 November 2016 at 07:27, Tudor Girba <tu...@tudorgirba.com> wrote: > Hi Igor, > > Please refrain from speaking down on people. > > Hi, Doru! I just wanted to hear you :) > If you have a concrete solution for how to do things, please feel free to > share it with us. We would be happy to learn from it. > > Well, there's so many solutions, that i even don't know what to offer, and given the potential of smalltalk, i wonder why you are not employing any. But in overall it is a quesition of storing most of your data on disk, and only small portion of it in image (in most optimal cases - only the portion that user sees/operates with). As i said to you before, you will hit this wall inevitably, no matter how much memory is available. So, what stops you from digging in that direction? Because even if you can fit all data in memory, consider how much time it takes for GC to scan 4+ Gb of memory, comparing to 100 MB or less. I don't think you'll find it convenient to work in environment where you'll have 2-3 seconds pauses between mouse clicks. So, of course, my tone is not acceptable, but its pain to see how people remain helpless without even thinking about doing what they need. We have Fuel for how many years now? So it can't be as easy as it is, just serialize the data and purge it from image, till it will be required again. Sure it will require some effort, but it is nothing comparing to day to day pain that you have to tolerate because of lack of solution. > Cheers, > Tudor > > > > On Nov 10, 2016, at 4:11 AM, Igor Stasenko <siguc...@gmail.com> wrote: > > > > Nice progress, indeed. > > Now i hope at the end of the day, the guys who doing data > mining/statistical analysis will finally shut up and happily be able > > to work with more bloat without need of learning a ways to properly > manage memory & resources, and implement them finally. > > But i guess, that won't be long silence, before they again start > screaming in despair: please help, my bloat doesn't fits into memory... :) > > > > On 9 November 2016 at 12:06, Sven Van Caekenberghe <s...@stfx.eu> wrote: > > OK, I am quite excited about the future possibilities of 64-bit Pharo. > So I played a bit more with the current test version [1], trying to push > the limits. In the past, it was only possible to safely allocate about > 1.5GB of memory even though a 32-bit process' limit is theoretically 4GB > (the OS and the VM need space too). > > > > Allocating a couple of 1GB ByteArrays is one way to push memory use, but > it feels a bit silly. So I loaded a bunch of projects (including Seaside) > to push the class/method counts (7K classes, 100K methods) and wrote a > script [2] that basically copies part of the class/method metadata > including 2 copies of each's methods source code as well as its AST > (bypassing the cache of course). This feels more like a real object graph. > > > > I had to create no less than 7 (SEVEN) copies (each kept open in an > inspector) to break through the mythical 4GB limit (real allocated & used > memory). > > > > > > > > I also have the impression that the image shrinking problem is gone > (closing everything frees memory, saving the image has it return to its > original size, 100MB in this case). > > > > Great work, thank you. Bright future again. > > > > Sven > > > > PS: Yes, GC is slower; No, I did not yet try to save such a large image. > > > > [1] > > > > VM here: http://bintray.com/estebanlm/pharo-vm/build#files/ > > Image here: http://files.pharo.org/get-files/60/pharo-64.zip > > > > [2] > > > > | meta | > > ASTCache reset. > > meta := Dictionary new. > > Smalltalk allClassesAndTraits do: [ :each | | classMeta methods | > > (classMeta := Dictionary new) > > at: #name put: each name asSymbol; > > at: #comment put: each comment; > > at: #definition put: each definition; > > at: #object put: each. > > methods := Dictionary new. > > classMeta at: #methods put: methods. > > each methodsDo: [ :method | | methodMeta | > > (methodMeta := Dictionary new) > > at: #name put: method selector; > > at: #source put: method sourceCode; > > at: #ast put: method ast; > > at: #args put: method argumentNames asArray; > > at: #formatted put: method ast formattedCode; > > at: #comment put: (method comment ifNotNil: [ :str | str > withoutQuoting ]); > > at: #object put: method. > > methods at: method selector put: methodMeta ]. > > meta at: each name asSymbol put: classMeta ]. > > meta. > > > > > > > > -- > > Sven Van Caekenberghe > > Proudly supporting Pharo > > http://pharo.org > > http://association.pharo.org > > http://consortium.pharo.org > > > > > > > > > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > -- > www.tudorgirba.com > www.feenk.com > > "We can create beautiful models in a vacuum. > But, to get them effective we have to deal with the inconvenience of > reality." > > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] AthensCairoSurface not getting garbage collected
If problem in ever-growing cache - try using identical object(s) as keys for cache, not newly-created-unique one, each time you adding new entry to cache :) or.. maybe cache is broken and does not releasing garbage anymore. On 8 July 2016 at 16:54, J.F. Rick <s...@je77.com> wrote: > I don't have enough evidence either way, but the signs point to no since > the applications that crash are not ones that use form-based paints. I > assume they wouldn't be affected by the flush. We did have one crash on a > form-based one where it crashed after running for 10 hours. My guess is > that one ran out of memory. That crash is probably resolved. But, I'll keep > everybody informed as I work more on it. > > Cheers, > > Jeff > > > On Thu, Jul 7, 2016 at 3:28 AM Alexandre Bergel <alexandre.ber...@me.com> > wrote: > >> Jeff, does this flush reduces the amount of crash you are experiencing? >> >> Alexandre >> >> > On Jul 6, 2016, at 9:01 PM, J.F. Rick <s...@je77.com> wrote: >> > >> > Nicolai, >> > >> > THANKS! That worked. I no longer have any AthensCairoCanvas hanging >> around after executing "CairoBackendCache flush". >> > >> > Cheers, >> > >> > Jeff >> > >> > On Sun, Jul 3, 2016 at 11:58 AM Nicolai Hess <nicolaih...@gmail.com> >> wrote: >> > Hi Jeff, >> > >> > if you use forms to paint on an AthensCairoCanvas, they are cached in >> the CairoBackendCache, >> > can you try to flush that cache whith >> > CairoBackendCache flush. >> > >> > >> > 2016-06-18 18:36 GMT+02:00 J.F. Rick <s...@je77.com>: >> > I'm using Athens rendering for my multi-touch applications on Pharo5. >> As part of that, I create a surface: >> > surface := AthensCairoSurface extent: bounds extent asIntegerPoint. >> > >> > Though the object creating that surface is deleted, the surface sticks >> around. So, each time I run the app, I get another instance of >> AthensCairoSurface hanging around. That means all the forms stick around as >> well. So my image can quickly grow towards the 1GB size. >> > >> > Is there anything I can do about that? Can I manually get the surface >> to delete itself? >> > >> > Cheers, >> > >> > Jeff >> > >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> -- Best regards, Igor Stasenko.
Re: [Pharo-dev] AthensCairoSurface not getting garbage collected
On 23 June 2016 at 16:19, J.F. Rick <s...@je77.com> wrote: > Are .dmp files useful? If so, I can share those. I do still get crashes > but they are far less since I only use one surface. > > Another thing that is happening is that the form-based paints are sticking > around though the form should have been collected. It seems like the way > that paints are being handled is changing in Athens development. I tried > upgrading but that broke things. Is there a way I can be at the bleeding > edge and contribute back to the Athens development? I can't do anything on > the C side but I can contribute on the Smalltalk side. > > Unfortunately, i am not in the bussiness right now to help with your problem. And i cannot teach everyone how to handle problems with hanging pointers nor mentor people how to write code to prevent risk of their appearance in a first place. It is a common problem of every system with garbage collector under the hood.. now its time for Athens to face it. Oh well, one more, one less.. Such thing will keep popping up time to time around the place, unless people start to think before coding :) I guess, someone who made those changes could help you better. > Cheers, > > Jeff > > On Thu, Jun 23, 2016 at 7:11 AM Igor Stasenko <siguc...@gmail.com> wrote: > >> On 18 June 2016 at 19:36, J.F. Rick <s...@je77.com> wrote: >> >>> I'm using Athens rendering for my multi-touch applications on Pharo5. As >>> part of that, I create a surface: >>> surface := AthensCairoSurface extent: bounds extent asIntegerPoint. >>> >>> Though the object creating that surface is deleted, the surface sticks >>> around. So, each time I run the app, I get another instance of >>> AthensCairoSurface hanging around. That means all the forms stick around as >>> well. So my image can quickly grow towards the 1GB size. >>> >>> Is there anything I can do about that? Can I manually get the surface >>> to delete itself? >>> >>> >> follow the pointers and look for the culprit, that holding it and not >> releasing. That's all i can advice. >> >> >>> Cheers, >>> >>> Jeff >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] AthensCairoSurface not getting garbage collected
On 18 June 2016 at 19:36, J.F. Rick <s...@je77.com> wrote: > I'm using Athens rendering for my multi-touch applications on Pharo5. As > part of that, I create a surface: > surface := AthensCairoSurface extent: bounds extent asIntegerPoint. > > Though the object creating that surface is deleted, the surface sticks > around. So, each time I run the app, I get another instance of > AthensCairoSurface hanging around. That means all the forms stick around as > well. So my image can quickly grow towards the 1GB size. > > Is there anything I can do about that? Can I manually get the surface to > delete itself? > > follow the pointers and look for the culprit, that holding it and not releasing. That's all i can advice. > Cheers, > > Jeff > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Athens Re: TxText model
On 7 April 2016 at 13:10, Nicolai Hess <nicolaih...@gmail.com> wrote: > > > 2016-04-07 11:15 GMT+02:00 Igor Stasenko <siguc...@gmail.com>: > >> >> >> On 7 April 2016 at 10:32, Nicolai Hess <nicolaih...@gmail.com> wrote: >> >>> >>> >>> 2016-04-06 16:58 GMT+02:00 Igor Stasenko <siguc...@gmail.com>: >>> >>>> >>>> >>>> On 6 April 2016 at 17:07, Nicolai Hess <nicolaih...@gmail.com> wrote: >>>> >>>>> >>>>> >>>>> 2016-04-06 10:56 GMT+02:00 Igor Stasenko <siguc...@gmail.com>: >>>>> >>>>>> >>>>>> >>>>>> On 6 April 2016 at 11:36, Nicolai Hess <nicolaih...@gmail.com> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks Igor. >>>>>>> Maybe some more Info? (I don't have much experience with this and >>>>>>> don't fully understand what is missing). >>>>>>> >>>>>>> >>>>>>>> 1. No support for vector graphics >>>>>>>> >>>>>>> >>>>>>> I know some parts of Athens (with Cairo font renderer and how it is >>>>>>> used in TxText) but at the moment >>>>>>> rendering a TextMorph in Athens works: >>>>>>> Morph comment asText asMorph openInSceneView >>>>>>> >>>>>> >>>>>> Sorry, missed to reply to that important point. >>>>>> It works because one good soul spent effort and helped me to finish >>>>>> implementation of a wrapper for Morph, to be able to render any morph >>>>>> into >>>>>> Form, and then render Form >>>>>> on Athens surface. >>>>>> >>>>> >>>>> Nah, actually it works a bit different. Many (Form)Canvas methods are >>>>> reimplemented on Athens API. But yes, I used some hacks as well. >>>>> >>>>> >>>> >>>> Didn't knew. >>>> Aha.. i see AthensCanvasWrapper. >>>> Ohh.. that's so much pain :) >>>> >>>> >>> As you are here and in a good mood for feedback, can you please answer >>> some >>> Athens questions or review some code changes / issue entries? >>> >>> I added some instance variables for AthensCairoPatternPaint >>> (origin, extent) This was needed for converting Morphics >>> GradientFillStyle to Athens pattern >>> paint. But I am unsure if this was the intended way to use them. >>> >>> There are protocols for creating gradient paints in Athens: >> >> createLinearGradient: aColorRamp start: aStartPoint stop: aStopPoint >> createRadialGradient: colorRamp center: aCenter radius: aRadius >> focalPoint: fp >> >> how you storing things inside or transform this information is orthogonal. >> From that perspective, anything what happens in AthensCairoPatternPaint >> is implementation detail. >> If you think that this protocol is not sufficient to define gradients, >> then >> fix it.. What happens on concrete implementation is last thing that >> should worry about. >> >> From my POV , two points and color ramp is enough to define linear >> gradient. >> Things like extent is a derived data, that can be obtained via simple >> calculations from original data. That why it wasn't there in a first place. >> >> I am interested on issue >>> 14800 AthensCanvas clipRect oddity (Aliaskei thinks the current behavior >>> is >>> on purpose ,but I am not sure). >>> >>> >> The intent was to make clipping work with Morphic.. >> > > Hm, I still don't know if the outcome was intended. > If you compare the two example codes, > the first defines a cliprect > translates the path transform > draws a rectangle (the green one), this rectangle is clipped (that is, the > cliprect is not translated - OK) > > The second example does the same, but defines again a cliprect after the > path transform. Now the rectangle is not clipped (by the first clip rect), > although the comment in > AthensCanvas says > "Note that the clipping rectangle is intersected with the currently active > clipping rectangle" > > If i remember the intent was to demonstrate that you can nest clipping operations. Ideally that should work as: - you clip in local coordinates - then you can translate/transform coordinates again - and again clip, but in new coordinates, but that still take into account the outer clipping. IIRC, Cairo doesn't allows nesting for clipping.. but i may be mistaken. -- Best regards, Igor Stasenko.
Re: [Pharo-dev] Athens Re: TxText model
On 7 April 2016 at 10:32, Nicolai Hess <nicolaih...@gmail.com> wrote: > > > 2016-04-06 16:58 GMT+02:00 Igor Stasenko <siguc...@gmail.com>: > >> >> >> On 6 April 2016 at 17:07, Nicolai Hess <nicolaih...@gmail.com> wrote: >> >>> >>> >>> 2016-04-06 10:56 GMT+02:00 Igor Stasenko <siguc...@gmail.com>: >>> >>>> >>>> >>>> On 6 April 2016 at 11:36, Nicolai Hess <nicolaih...@gmail.com> wrote: >>>> >>>>> >>>>> >>>>> Thanks Igor. >>>>> Maybe some more Info? (I don't have much experience with this and >>>>> don't fully understand what is missing). >>>>> >>>>> >>>>>> 1. No support for vector graphics >>>>>> >>>>> >>>>> I know some parts of Athens (with Cairo font renderer and how it is >>>>> used in TxText) but at the moment >>>>> rendering a TextMorph in Athens works: >>>>> Morph comment asText asMorph openInSceneView >>>>> >>>> >>>> Sorry, missed to reply to that important point. >>>> It works because one good soul spent effort and helped me to finish >>>> implementation of a wrapper for Morph, to be able to render any morph into >>>> Form, and then render Form >>>> on Athens surface. >>>> >>> >>> Nah, actually it works a bit different. Many (Form)Canvas methods are >>> reimplemented on Athens API. But yes, I used some hacks as well. >>> >>> >> >> Didn't knew. >> Aha.. i see AthensCanvasWrapper. >> Ohh.. that's so much pain :) >> >> > As you are here and in a good mood for feedback, can you please answer some > Athens questions or review some code changes / issue entries? > > I added some instance variables for AthensCairoPatternPaint > (origin, extent) This was needed for converting Morphics GradientFillStyle > to Athens pattern > paint. But I am unsure if this was the intended way to use them. > > There are protocols for creating gradient paints in Athens: createLinearGradient: aColorRamp start: aStartPoint stop: aStopPoint createRadialGradient: colorRamp center: aCenter radius: aRadius focalPoint: fp how you storing things inside or transform this information is orthogonal. >From that perspective, anything what happens in AthensCairoPatternPaint is implementation detail. If you think that this protocol is not sufficient to define gradients, then fix it.. What happens on concrete implementation is last thing that should worry about. >From my POV , two points and color ramp is enough to define linear gradient. Things like extent is a derived data, that can be obtained via simple calculations from original data. That why it wasn't there in a first place. I am interested on issue > 14800 AthensCanvas clipRect oddity (Aliaskei thinks the current behavior is > on purpose ,but I am not sure). > > The intent was to make clipping work with Morphic.. This is true that morphic needs cliprect to be smart and not try to draw anything if it is fully outside clipped areas.. So, this is purely for optimization purpose. But i would prefer to have a consistent clipping model first, i.e.: - clipping using local coordinates - you can use any shape for clipping and then think how to adapt users with their concrete cases. That may, indeed make accessing such properties like clipRect impossible to get, since clipped area cannot be represented by a simple rectangle anymore. But then you could, perhaps instead provide a protocol to tell if given point/bounds/shape is fully outside currently clipped region(s) or not. And thus, you don't have to worry about cliprect anymore. AthensPathSegment: > I understand how they use the visit: messages but I don't understand the > #accept: or the #sendCommandTo: methods, are they used? > > The intent is to use it for path conversion/transformation etc. It is because we cannot guarantee that all backends will support various kinds of path segments, that Athens providing to user. And so, we need a small private toolset for converting some segments into simpler form, in case of need. So , it is there when you need to iterate over path for things like converting it to polygon etc. But that part needs review and cleanup, because it smells... Aliaksei fixed a bug in > CairoFreetypeFontRenderer>>#glyphsOf:from:to: > (the bug was: sometimes, some characters uses glyphs with wrong size). > > I think some AthensText classes are obsolete: > AthensTextScanner/AthensParagraph/AthensTextMorph/AthensPluggableTextMorph > Can we remove them? > > Well, if i remember, there are some leftovers from attempt to make text rendering it at least partially work with Balloon backend. While some other is result of failed attempt to make anything with TextMorph. So, nobody will cry if you clean this mess. -- Best regards, Igor Stasenko.
Re: [Pharo-dev] TxText model
On 6 April 2016 at 20:31, Nicolai Hess <nicolaih...@gmail.com> wrote: > > > 2016-04-06 18:00 GMT+02:00 Igor Stasenko <siguc...@gmail.com>: > >> >> >> On 6 April 2016 at 18:34, Nicolai Hess <nicolaih...@gmail.com> wrote: >> >>> >>> Am 06.04.2016 5:21 nachm. schrieb "Igor Stasenko" <siguc...@gmail.com>: >>> > >>> > btw, >>> > >>> > if you wanna feel a difference, why we wanted vector based rendering, >>> by yourself, open: >>> > >>> > Morph comment asText asMorph openInSceneView >>> > >>> > and then >>> > >>> > | sceneView view | >>> > sceneView := AthensSceneView new. >>> > view := TxAthensLayoutView on: Morph comment asTxModel extent: 400@400. >>> > >>> > sceneView scene: view. >>> > sceneView openInWindow >>> > >>> > >>> > and try zooming it in and out with mouse wheel. >>> > >>> > >>> >>> I know it's limitation. My point was, that it is not impossible, or >>> depends an the model Text vs. TxModel, alone. >>> >> Of course it doesn't depends on either of those. But it wasn't an answer >> concerning model, but you question why i had to abandon idea to keep using >> DisplayScanner & friends. >> > > Sure, but as you talked about limitiations solved by TxText, I thought > about limitation for building editor/tools around Text or TxText. > I see that you had rendering vector based graphics with TxText and Athens. > What I want to see, is a Text-Tool framework for building custom editors > or easily add features (code tools or tools for other kinds of text). > Rubric comes close, it has some good features for text decorations. > Twisty looks promisinig too, I like that it is build on similar classes > like TxText but looks more finished. > (As it is based on TxText (or a fork) maybe it isn't that difficult to add > rendering on athens ?) > > I payed attention to make things modular. Things like model, layout and view, and then text editor, forming layers and replaceable or close to it. As in snippet of code above, it demonstrates, that you can easily use just layout view, just for text rendering, without paying any attention to higher level things, like text editor, events and UI. Now try doing this with morphic TextMorph. It is far from ideal, and missing a number of features. So, if you see how you can improved - feel free to do it. > >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] TxText model
On 6 April 2016 at 18:34, Nicolai Hess <nicolaih...@gmail.com> wrote: > > Am 06.04.2016 5:21 nachm. schrieb "Igor Stasenko" <siguc...@gmail.com>: > > > > btw, > > > > if you wanna feel a difference, why we wanted vector based rendering, by > yourself, open: > > > > Morph comment asText asMorph openInSceneView > > > > and then > > > > | sceneView view | > > sceneView := AthensSceneView new. > > view := TxAthensLayoutView on: Morph comment asTxModel extent: 400@400. > > > > sceneView scene: view. > > sceneView openInWindow > > > > > > and try zooming it in and out with mouse wheel. > > > > > > I know it's limitation. My point was, that it is not impossible, or > depends an the model Text vs. TxModel, alone. > Of course it doesn't depends on either of those. But it wasn't an answer concerning model, but you question why i had to abandon idea to keep using DisplayScanner & friends. -- Best regards, Igor Stasenko.
Re: [Pharo-dev] TxText model
btw, if you wanna feel a difference, why we wanted vector based rendering, by yourself, open: Morph comment asText asMorph openInSceneView and then | sceneView view | sceneView := AthensSceneView new. view := TxAthensLayoutView on: Morph comment asTxModel extent: 400@400. sceneView scene: view. sceneView openInWindow and try zooming it in and out with mouse wheel. On 6 April 2016 at 17:58, Igor Stasenko <siguc...@gmail.com> wrote: > > > On 6 April 2016 at 17:07, Nicolai Hess <nicolaih...@gmail.com> wrote: > >> >> >> 2016-04-06 10:56 GMT+02:00 Igor Stasenko <siguc...@gmail.com>: >> >>> >>> >>> On 6 April 2016 at 11:36, Nicolai Hess <nicolaih...@gmail.com> wrote: >>> >>>> >>>> >>>> Thanks Igor. >>>> Maybe some more Info? (I don't have much experience with this and don't >>>> fully understand what is missing). >>>> >>>> >>>>> 1. No support for vector graphics >>>>> >>>> >>>> I know some parts of Athens (with Cairo font renderer and how it is >>>> used in TxText) but at the moment >>>> rendering a TextMorph in Athens works: >>>> Morph comment asText asMorph openInSceneView >>>> >>> >>> Sorry, missed to reply to that important point. >>> It works because one good soul spent effort and helped me to finish >>> implementation of a wrapper for Morph, to be able to render any morph into >>> Form, and then render Form >>> on Athens surface. >>> >> >> Nah, actually it works a bit different. Many (Form)Canvas methods are >> reimplemented on Athens API. But yes, I used some hacks as well. >> >> > > Didn't knew. > Aha.. i see AthensCanvasWrapper. > Ohh.. that's so much pain :) > > > >> So, that is why it 'works' :) >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] TxText model
On 6 April 2016 at 17:07, Nicolai Hess <nicolaih...@gmail.com> wrote: > > > 2016-04-06 10:56 GMT+02:00 Igor Stasenko <siguc...@gmail.com>: > >> >> >> On 6 April 2016 at 11:36, Nicolai Hess <nicolaih...@gmail.com> wrote: >> >>> >>> >>> Thanks Igor. >>> Maybe some more Info? (I don't have much experience with this and don't >>> fully understand what is missing). >>> >>> >>>> 1. No support for vector graphics >>>> >>> >>> I know some parts of Athens (with Cairo font renderer and how it is used >>> in TxText) but at the moment >>> rendering a TextMorph in Athens works: >>> Morph comment asText asMorph openInSceneView >>> >> >> Sorry, missed to reply to that important point. >> It works because one good soul spent effort and helped me to finish >> implementation of a wrapper for Morph, to be able to render any morph into >> Form, and then render Form >> on Athens surface. >> > > Nah, actually it works a bit different. Many (Form)Canvas methods are > reimplemented on Athens API. But yes, I used some hacks as well. > > Didn't knew. Aha.. i see AthensCanvasWrapper. Ohh.. that's so much pain :) > So, that is why it 'works' :) >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] TxText model
On 6 April 2016 at 11:56, Denis Kudriashov <dionisi...@gmail.com> wrote: > Hi > > 2016-04-06 9:07 GMT+02:00 Nicolai Hess <nicolaih...@gmail.com>: > >> What are the main problems with Text, Paragraph, ... and other old >> TextComponents? > > > I don't want to write crappy words. But to understand what was wrong you > can try with them: > >- remove blinking cursor for specific morph instance >- hide selection or change it color for specific morph instance >- implement validation for input when only digits are allowed >- implement masked fields >- try to make all this composable > > It seems that first two items are really simple tasks. But it is huge pain > and hacks at the end. > Yes, Denis, that was i did not mentioned. But as i said my main focus was not trying to fix all of the above , but to enable vector-based rendering for text. The rest was coming as a bonus and future work. Because else, all of it worth nothing if you cannot even render text with Athens.. -- Best regards, Igor Stasenko.
Re: [Pharo-dev] TxText model
On 6 April 2016 at 11:36, Nicolai Hess <nicolaih...@gmail.com> wrote: > > > Thanks Igor. > Maybe some more Info? (I don't have much experience with this and don't > fully understand what is missing). > > >> 1. No support for vector graphics >> > > I know some parts of Athens (with Cairo font renderer and how it is used > in TxText) but at the moment > rendering a TextMorph in Athens works: > Morph comment asText asMorph openInSceneView > Sorry, missed to reply to that important point. It works because one good soul spent effort and helped me to finish implementation of a wrapper for Morph, to be able to render any morph into Form, and then render Form on Athens surface. So, that is why it 'works' :) -- Best regards, Igor Stasenko.
Re: [Pharo-dev] TxText model
On 6 April 2016 at 11:36, Nicolai Hess <nicolaih...@gmail.com> wrote: > > > 2016-04-06 9:59 GMT+02:00 Igor Stasenko <siguc...@gmail.com>: > >> >> >> On 6 April 2016 at 10:07, Nicolai Hess <nicolaih...@gmail.com> wrote: >> >>> >>> >>> 2016-04-06 7:57 GMT+02:00 p...@highoctane.be <p...@highoctane.be>: >>> >>>> >>>> >>>> On Wed, Apr 6, 2016 at 2:07 AM, Sean P. DeNigris <s...@clipperadams.com >>>> > wrote: >>>> >>>>> philippe.b...@highoctane.be wrote >>>>> > So, I ended up in ParagraphEditor, Text attributes etc. >>>>> >>>>> Ugh. How many beautiful projects have died because of Paragraph and >>>>> associated editors?! >>>> >>>> >>>> A damn lot, I can tell you. >>>> >>>> >>>>> This is where my vim keybindings experiment came >>>>> screeching to a halt. >>>>> >>>>> >>> What are the main problems with Text, Paragraph, ... and other old >>> TextComponents? >>> >> >> > Thanks Igor. > Maybe some more Info? (I don't have much experience with this and don't > fully understand what is missing). > > >> 1. No support for vector graphics >> > > I know some parts of Athens (with Cairo font renderer and how it is used > in TxText) but at the moment > rendering a TextMorph in Athens works: > Morph comment asText asMorph openInSceneView > I don't see where the models (Text vs. TxText) is the problem. > > >> 2. Most operations are bound to text size. >> > > In what use cases is this a problem ? (Paragraph and DisplayScanner have > good support for justified text (left / right / center), indentation > wrapping and (I don't know if this works in pharo anymore but squeak had) > even filling text in arbitary shaped polygons ( that was pretty cool). > And even for text of different size and with different emphasis. > > It is about text size (the total number of characters in Text). I am aware about those features in Text and of course i feel a pity that we lost some of them in new TxText, because there was so many to make everything at once. > >> >>> And how are these solved with TxText? >>> >>> >>> >> 1. By implementing new view, rendered by Athens >> > > Ok ,but this could have be done (or is done) with the old Text class as > well (no?) > It could be done. Except that model for text scanning and layout in DisplayScanner & friends are nailed to pixel grid. (You know , all that glyph width + 1, line height - 1.. and things like that all over the place). It is virtually impossible to turn that into vector-compliant thing. Because it is pixel based from its very birth.. and trying to convert it to vector form, would be going against the nature of code itself and all design decisions made, centered around the fact that we dealing with pixels. You right, that asking this question. I was attempted to approach it , because for a lazy person like me, i didn't wanted to start from scratch.. But after wasting couple weeks on that, i came to conclusion that it is hopeless. Or maybe because i incapable to do it.. choose what you like most :) > >> 2. By introducing new model for storing text to overcome mentioned >> limitations. >> > > But this is exactly what I don't understand. How is storing the text in > TxText model better than the old Text. > Given that we don't have any (beside TxWorkspace) tools actually using > this model. > I have a faint idea how TxText could be easier for building advanced > tools, but I don't see that this > model is a crucial point in developing good/better tools for text editing. > > I giving you a hint: try opening a hundred kilobytes text in TextMorph. Or just a method with lots of source code in it (we have a number of those in image) -- Best regards, Igor Stasenko.
Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place
That explains, why, there initially certain features of Cairo, that not exposed by Athens. It is not because we can't or just don't care.. we do.. But only after we can see that it consistent with rest of API and can be easily implemented on most of other potential backends. Yes, i am talking about that damn 'minimal common denominator' problem. :) Oh, and also i forgot to mention, that there could be also 2 more potential backends: - OpenVG and - Quartz, that is a vector graphics library for Mac OS On 6 April 2016 at 11:23, Igor Stasenko <siguc...@gmail.com> wrote: > > > On 6 April 2016 at 11:14, Thierry Goubier <thierry.goub...@gmail.com> > wrote: > >> >> >> 2016-04-06 10:07 GMT+02:00 Igor Stasenko <siguc...@gmail.com>: >> >>> >>> >>> On 6 April 2016 at 10:35, Nicolai Hess <nicolaih...@gmail.com> wrote: >>> >>>> >>>> I made some fixes for AthensBalloon (not all are integrated yet, some >>>> parts are just experimental and needs more tests), the idea is to have >>>> AthensBalloon at least not crash or throwing errors, even if not all >>>> features are supported. >>>> >>> >>> Much, much, much appreciated. The whole point of existence of Balloon >>> backend for Athens was to use it as a proving ground that Athens can stay >>> backend neutral, and its API allows to stay it like that. >>> From that perspective, any feature that offered by any backend should >>> find its way via API, but not thrown into play just because we can. >>> >> >> Cool. I played with AthensBalloon a way back; but some stuff wasn't >> working. Good to know it has improved, and this is within Athens objective >> to be backend-neutral. >> >> >>> As i mentioned before, if we would be making Cairo wrapper, then there >>> no reason to call it Athens. It could be something like 'CairoPharo'. >>> >>> And i kept mentioned over and over again on all presentations related to >>> Athens, that it is not Cairo. >>> >>> But at the moment, no one cares about non-cairo-athens. All users just >>>> directly use AthensCairoCanvas/AthensCairoSurface. >>>> I had a bug report for discussion about how to make some kind of >>>> factory that would create the appropriate Athens backend. >>>> >>>> Is there still some interest on AthensBalloon or to make athens more >>>> independent from cairo? >>>> >>>> >>>> >>> >>> It always been. But didn't have much time to make that happen. >>> For instance, i dream to make an OpenGL backend for Athens.. but i had >>> no chance to put my hands on that topic so far. >>> >> >> It is interesting to know, because this means you probably already have >> an idea about how to implement that :) >> >> Of course i do. There are an open-source ShivaVG project that implements > OpenVG using OpenGL. > And i was looking how i could use it for insights and 'steal' some code in > order to do it :) > > https://sourceforge.net/projects/shivavg/ > > >> Regards, >> >> Thierry >> > > > > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place
On 6 April 2016 at 11:14, Thierry Goubier <thierry.goub...@gmail.com> wrote: > > > 2016-04-06 10:07 GMT+02:00 Igor Stasenko <siguc...@gmail.com>: > >> >> >> On 6 April 2016 at 10:35, Nicolai Hess <nicolaih...@gmail.com> wrote: >> >>> >>> I made some fixes for AthensBalloon (not all are integrated yet, some >>> parts are just experimental and needs more tests), the idea is to have >>> AthensBalloon at least not crash or throwing errors, even if not all >>> features are supported. >>> >> >> Much, much, much appreciated. The whole point of existence of Balloon >> backend for Athens was to use it as a proving ground that Athens can stay >> backend neutral, and its API allows to stay it like that. >> From that perspective, any feature that offered by any backend should >> find its way via API, but not thrown into play just because we can. >> > > Cool. I played with AthensBalloon a way back; but some stuff wasn't > working. Good to know it has improved, and this is within Athens objective > to be backend-neutral. > > >> As i mentioned before, if we would be making Cairo wrapper, then there no >> reason to call it Athens. It could be something like 'CairoPharo'. >> >> And i kept mentioned over and over again on all presentations related to >> Athens, that it is not Cairo. >> >> But at the moment, no one cares about non-cairo-athens. All users just >>> directly use AthensCairoCanvas/AthensCairoSurface. >>> I had a bug report for discussion about how to make some kind of factory >>> that would create the appropriate Athens backend. >>> >>> Is there still some interest on AthensBalloon or to make athens more >>> independent from cairo? >>> >>> >>> >> >> It always been. But didn't have much time to make that happen. >> For instance, i dream to make an OpenGL backend for Athens.. but i had no >> chance to put my hands on that topic so far. >> > > It is interesting to know, because this means you probably already have an > idea about how to implement that :) > > Of course i do. There are an open-source ShivaVG project that implements OpenVG using OpenGL. And i was looking how i could use it for insights and 'steal' some code in order to do it :) https://sourceforge.net/projects/shivavg/ > Regards, > > Thierry > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place
I started working on Athens by picking up a previous work by Cyrille (if i'm not mistaken). And his work also predated by Rome plugin , that was done by (and here my memory fails me).. Originally it was looked as a simple wrapper of Cairo library, reflecting its design and API straightly and sharply. We had a discussion at that time about this and picked a direction. The reason why we don't want it to be just a Cairo wrapper is obvious. (if not, ask, i will list them here). The heaviest influence to Athens design comes from OpenVG standard. I like it, because it describes all things quite clear and with much detail. On 6 April 2016 at 11:07, Igor Stasenko <siguc...@gmail.com> wrote: > > > On 6 April 2016 at 10:35, Nicolai Hess <nicolaih...@gmail.com> wrote: > >> >> >> 2016-04-05 16:31 GMT+02:00 Igor Stasenko <siguc...@gmail.com>: >> >>> >>> >>> On 5 April 2016 at 17:27, Igor Stasenko <siguc...@gmail.com> wrote: >>> >>>> >>>> >>>> On 5 April 2016 at 16:29, Aliaksei Syrel <alex.sy...@gmail.com> wrote: >>>> >>>>> Now let's take a look at this code: >>>>> >>>>> drawOnSpartaCanvas: aCanvas >>>>> >>>>>> aCanvas >>>>>> clipPreserveBy: self shape during: [ >>>>>> aCanvas paintGroup: [ >>>>>> aCanvas setPaint: self shape fillPaint. >>>>>> aCanvas fillPreserve. >>>>>> aCanvas paintMode source. >>>>>> aCanvas setStrokePaint: self shape strokePaint. >>>>>> aCanvas stroke ] ] >>>>> >>>>> >>>>> You may be curious why it is so ugly :) Make it work - make it right - >>>>> make it fast. We are on the first etappe, because I invested zero time in >>>>> rendering stuff. >>>>> >>>>> What you see is the minimal amount of cairo primitive calls that are >>>>> needed to render not overlapping fill and stroke. Clipping is needed to >>>>> make sure that stroke does not get rendered outside of a path. Group is >>>>> needed to have transparent target in order to make source paint mode work >>>>> as expected. Compared to image_surface group, it in this case allows to >>>>> preserve clip and current cairo state which is pushed to stack during >>>>> push_group and restored during pop_group_to_source. fillPreserve allows to >>>>> reuse the same path as used for clipping before saving cpu time on loading >>>>> path. >>>>> >>>>> Yes, i understand that. You are forced to do that. And it is ugly not >>>> because of all you listed above, it ugly because you could just use a >>>> cascade: >>>> >>>> aCanvas setPaint: self shape fillPaint; >>>> fillPreserve; >>>>paintMode source; >>>>setStrokePaint: self shape strokePaint; >>>> stroke >>>> >>>> (something like that) >>>> but yeah.. that can wait .. since it is still work in progress. I agree. >>>> >>>> >>>>> It is implemented in canvas specific method after dispatch though >>>>> canvas, so we are allowed to use canvas specific api, for example groups. >>>>> >>>>> How to model stroke, fillPreserve and paintModein terms of Athens? >>>>> >>>>> >>>> A good question. And i don't have an answer to it , ready for you. >>>> 1. Stroke can be expressed as a special kind of paint. And that how its >>>> done in Athens. >>>> >>>> 2. What fillPreserve is, is can't find it in source code? Some >>>> hot-swapping and preserving context state , i guess. >>>> >>>> 3. As for paint mode, it is already in Athens, so why you asking? You >>>> don't like how it is done or what? >>>> >>>> >>> or maybe you meant how to group those operation and express them as >>> command group? >>> I have no simple answer here. Because this is root points of the core of >>> graphics engine. From one side, you want such things be exposed to user, >>> and from other you want a higher dimension concepts/operations to be >>> allowed by combining those. >>> There's no simple way. I would just stop at this level, letting user to >>> decide how he wants to play with those pieces to achieve results he wants. >>> >> >> >> Grouping and Context save/restore are g
Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place
On 6 April 2016 at 10:35, Nicolai Hess <nicolaih...@gmail.com> wrote: > > > 2016-04-05 16:31 GMT+02:00 Igor Stasenko <siguc...@gmail.com>: > >> >> >> On 5 April 2016 at 17:27, Igor Stasenko <siguc...@gmail.com> wrote: >> >>> >>> >>> On 5 April 2016 at 16:29, Aliaksei Syrel <alex.sy...@gmail.com> wrote: >>> >>>> Now let's take a look at this code: >>>> >>>> drawOnSpartaCanvas: aCanvas >>>> >>>>> aCanvas >>>>> clipPreserveBy: self shape during: [ >>>>> aCanvas paintGroup: [ >>>>> aCanvas setPaint: self shape fillPaint. >>>>> aCanvas fillPreserve. >>>>> aCanvas paintMode source. >>>>> aCanvas setStrokePaint: self shape strokePaint. >>>>> aCanvas stroke ] ] >>>> >>>> >>>> You may be curious why it is so ugly :) Make it work - make it right - >>>> make it fast. We are on the first etappe, because I invested zero time in >>>> rendering stuff. >>>> >>>> What you see is the minimal amount of cairo primitive calls that are >>>> needed to render not overlapping fill and stroke. Clipping is needed to >>>> make sure that stroke does not get rendered outside of a path. Group is >>>> needed to have transparent target in order to make source paint mode work >>>> as expected. Compared to image_surface group, it in this case allows to >>>> preserve clip and current cairo state which is pushed to stack during >>>> push_group and restored during pop_group_to_source. fillPreserve allows to >>>> reuse the same path as used for clipping before saving cpu time on loading >>>> path. >>>> >>>> Yes, i understand that. You are forced to do that. And it is ugly not >>> because of all you listed above, it ugly because you could just use a >>> cascade: >>> >>> aCanvas setPaint: self shape fillPaint; >>> fillPreserve; >>>paintMode source; >>>setStrokePaint: self shape strokePaint; >>> stroke >>> >>> (something like that) >>> but yeah.. that can wait .. since it is still work in progress. I agree. >>> >>> >>>> It is implemented in canvas specific method after dispatch though >>>> canvas, so we are allowed to use canvas specific api, for example groups. >>>> >>>> How to model stroke, fillPreserve and paintModein terms of Athens? >>>> >>>> >>> A good question. And i don't have an answer to it , ready for you. >>> 1. Stroke can be expressed as a special kind of paint. And that how its >>> done in Athens. >>> >>> 2. What fillPreserve is, is can't find it in source code? Some >>> hot-swapping and preserving context state , i guess. >>> >>> 3. As for paint mode, it is already in Athens, so why you asking? You >>> don't like how it is done or what? >>> >>> >> or maybe you meant how to group those operation and express them as >> command group? >> I have no simple answer here. Because this is root points of the core of >> graphics engine. From one side, you want such things be exposed to user, >> and from other you want a higher dimension concepts/operations to be >> allowed by combining those. >> There's no simple way. I would just stop at this level, letting user to >> decide how he wants to play with those pieces to achieve results he wants. >> > > > Grouping and Context save/restore are good additions - I think. > > But it is true, that we should care about the api of Athens and not just > add things that happens to be possible, because we use cairo as a backend. > > I made some fixes for AthensBalloon (not all are integrated yet, some > parts are just experimental and needs more tests), the idea is to have > AthensBalloon at least not crash or throwing errors, even if not all > features are supported. > Much, much, much appreciated. The whole point of existence of Balloon backend for Athens was to use it as a proving ground that Athens can stay backend neutral, and its API allows to stay it like that. >From that perspective, any feature that offered by any backend should find its way via API, but not thrown into play just because we can. As i mentioned before, if we would be making Cairo wrapper, then there no reason to call it Athens. It could be something like 'CairoPharo'. And i kept mentioned over and over again on all presentations related to Athens, that it is not Cairo. But at th
Re: [Pharo-dev] TxText model
On 6 April 2016 at 10:07, Nicolai Hess <nicolaih...@gmail.com> wrote: > > > 2016-04-06 7:57 GMT+02:00 p...@highoctane.be <p...@highoctane.be>: > >> >> >> On Wed, Apr 6, 2016 at 2:07 AM, Sean P. DeNigris <s...@clipperadams.com> >> wrote: >> >>> philippe.b...@highoctane.be wrote >>> > So, I ended up in ParagraphEditor, Text attributes etc. >>> >>> Ugh. How many beautiful projects have died because of Paragraph and >>> associated editors?! >> >> >> A damn lot, I can tell you. >> >> >>> This is where my vim keybindings experiment came >>> screeching to a halt. >>> >>> > What are the main problems with Text, Paragraph, ... and other old > TextComponents? > 1. No support for vector graphics 2. Most operations are bound to text size. > And how are these solved with TxText? > > > 1. By implementing new view, rendered by Athens 2. By introducing new model for storing text to overcome mentioned limitations. > >>> >>> - >>> Cheers, >>> Sean >>> -- >>> View this message in context: >>> http://forum.world.st/TxText-model-tp4888199p4888515.html >>> Sent from the Pharo Smalltalk Developers mailing list archive at >>> Nabble.com. >>> >>> >> > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place
On 5 April 2016 at 17:27, Igor Stasenko <siguc...@gmail.com> wrote: > > > On 5 April 2016 at 16:29, Aliaksei Syrel <alex.sy...@gmail.com> wrote: > >> Now let's take a look at this code: >> >> drawOnSpartaCanvas: aCanvas >> >>> aCanvas >>> clipPreserveBy: self shape during: [ >>> aCanvas paintGroup: [ >>> aCanvas setPaint: self shape fillPaint. >>> aCanvas fillPreserve. >>> aCanvas paintMode source. >>> aCanvas setStrokePaint: self shape strokePaint. >>> aCanvas stroke ] ] >> >> >> You may be curious why it is so ugly :) Make it work - make it right - >> make it fast. We are on the first etappe, because I invested zero time in >> rendering stuff. >> >> What you see is the minimal amount of cairo primitive calls that are >> needed to render not overlapping fill and stroke. Clipping is needed to >> make sure that stroke does not get rendered outside of a path. Group is >> needed to have transparent target in order to make source paint mode work >> as expected. Compared to image_surface group, it in this case allows to >> preserve clip and current cairo state which is pushed to stack during >> push_group and restored during pop_group_to_source. fillPreserve allows to >> reuse the same path as used for clipping before saving cpu time on loading >> path. >> >> Yes, i understand that. You are forced to do that. And it is ugly not > because of all you listed above, it ugly because you could just use a > cascade: > > aCanvas setPaint: self shape fillPaint; > fillPreserve; >paintMode source; >setStrokePaint: self shape strokePaint; > stroke > > (something like that) > but yeah.. that can wait .. since it is still work in progress. I agree. > > >> It is implemented in canvas specific method after dispatch though canvas, >> so we are allowed to use canvas specific api, for example groups. >> >> How to model stroke, fillPreserve and paintModein terms of Athens? >> >> > A good question. And i don't have an answer to it , ready for you. > 1. Stroke can be expressed as a special kind of paint. And that how its > done in Athens. > > 2. What fillPreserve is, is can't find it in source code? Some > hot-swapping and preserving context state , i guess. > > 3. As for paint mode, it is already in Athens, so why you asking? You > don't like how it is done or what? > > or maybe you meant how to group those operation and express them as command group? I have no simple answer here. Because this is root points of the core of graphics engine. From one side, you want such things be exposed to user, and from other you want a higher dimension concepts/operations to be allowed by combining those. There's no simple way. I would just stop at this level, letting user to decide how he wants to play with those pieces to achieve results he wants. > >> Cheers, >> Alex >> >> On Tue, Apr 5, 2016 at 3:15 PM, Aliaksei Syrel <alex.sy...@gmail.com> >> wrote: >> >>> Hello Igor >>> >>> Thanks for extensive design explanation and effort! >>> Issues you mentioned in previous emails are important and need to be >>> addressed :) >>> fill(), stroke() fillPreserve() strokePreserve() need to disappear in >>> the end. We will come back to them later. >>> >>> Let me tell a few words about Sparta. >>> Sparta implements Athens interface api (excluding some experimental >>> stuff to test possible performance boost in a few places) and does not have >>> task to remove Athens style and abstractions. Ideally Sparta will be >>> AthensCairo for bloc. I'm looking forward for your help :) >>> >>> Here are some aspects in AthensCairo that Sparta tries to address in >>> first place: >>> >>>- *Clipping in local coordinates*. It is critical in Bloc. You >>>implemented AthensCairo to have vector based rendering in Morphic and >>> Pharo >>>in general. Morphic lives in global coordinates, so your choice to clip >>> in >>>global coordinate is perfect! At the same time global clipping in bloc >>> adds >>>complexity. Sparta clips always in local coordinates (user space in cairo >>>terminology). >>>- *Clip by arbitrary path*. Athens and AthenCairo expect to see >>>aRectangle as clipping region - your wise choice for morphic. In bloc I >>>would have clipping by arbitrary path. clipBy:during: gets aPath. >>>Rectangle/Color is polymorphic with path/paint in Sparta >>>- *Support o
Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place
On 5 April 2016 at 16:29, Aliaksei Syrel <alex.sy...@gmail.com> wrote: > Now let's take a look at this code: > > drawOnSpartaCanvas: aCanvas > >> aCanvas >> clipPreserveBy: self shape during: [ >> aCanvas paintGroup: [ >> aCanvas setPaint: self shape fillPaint. >> aCanvas fillPreserve. >> aCanvas paintMode source. >> aCanvas setStrokePaint: self shape strokePaint. >> aCanvas stroke ] ] > > > You may be curious why it is so ugly :) Make it work - make it right - > make it fast. We are on the first etappe, because I invested zero time in > rendering stuff. > > What you see is the minimal amount of cairo primitive calls that are > needed to render not overlapping fill and stroke. Clipping is needed to > make sure that stroke does not get rendered outside of a path. Group is > needed to have transparent target in order to make source paint mode work > as expected. Compared to image_surface group, it in this case allows to > preserve clip and current cairo state which is pushed to stack during > push_group and restored during pop_group_to_source. fillPreserve allows to > reuse the same path as used for clipping before saving cpu time on loading > path. > > Yes, i understand that. You are forced to do that. And it is ugly not because of all you listed above, it ugly because you could just use a cascade: aCanvas setPaint: self shape fillPaint; fillPreserve; paintMode source; setStrokePaint: self shape strokePaint; stroke (something like that) but yeah.. that can wait .. since it is still work in progress. I agree. > It is implemented in canvas specific method after dispatch though canvas, > so we are allowed to use canvas specific api, for example groups. > > How to model stroke, fillPreserve and paintModein terms of Athens? > > A good question. And i don't have an answer to it , ready for you. 1. Stroke can be expressed as a special kind of paint. And that how its done in Athens. 2. What fillPreserve is, is can't find it in source code? Some hot-swapping and preserving context state , i guess. 3. As for paint mode, it is already in Athens, so why you asking? You don't like how it is done or what? > > Cheers, > Alex > > On Tue, Apr 5, 2016 at 3:15 PM, Aliaksei Syrel <alex.sy...@gmail.com> > wrote: > >> Hello Igor >> >> Thanks for extensive design explanation and effort! >> Issues you mentioned in previous emails are important and need to be >> addressed :) >> fill(), stroke() fillPreserve() strokePreserve() need to disappear in the >> end. We will come back to them later. >> >> Let me tell a few words about Sparta. >> Sparta implements Athens interface api (excluding some experimental stuff >> to test possible performance boost in a few places) and does not have task >> to remove Athens style and abstractions. Ideally Sparta will be AthensCairo >> for bloc. I'm looking forward for your help :) >> >> Here are some aspects in AthensCairo that Sparta tries to address in >> first place: >> >>- *Clipping in local coordinates*. It is critical in Bloc. You >>implemented AthensCairo to have vector based rendering in Morphic and >> Pharo >>in general. Morphic lives in global coordinates, so your choice to clip in >>global coordinate is perfect! At the same time global clipping in bloc >> adds >>complexity. Sparta clips always in local coordinates (user space in cairo >>terminology). >>- *Clip by arbitrary path*. Athens and AthenCairo expect to see >>aRectangle as clipping region - your wise choice for morphic. In bloc I >>would have clipping by arbitrary path. clipBy:during: gets aPath. >>Rectangle/Color is polymorphic with path/paint in Sparta >>- *Support of groups*. (maybe user-level aspect? like shadows) Groups >>are powerful in cairo (do they exist outside of cairo?) and allow to draw >>both transparent fill and stroke without overlapping using only one path. >>On class side of BlElement there are examples (exampleCircle) that show >>such behavior. >>- *Do not maintain and set pathTransformation before each >>render-dependent action.* Questionable but what if Canvas will not >>maintain current state of pathTransform? Instead all transformations can >> be >>directly applied on cairo_t using native calls. If there is a need to get >>actual matrix we can ask cairo directly. From my perspective it simplifies >>transformation stuff a little bit. >>- *Benefit from cairo_save and cairo_restore.* AthensCairo maintains >>state manually by setting transformation matrix and clip. Instead we could >
Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place
formance boost in a few places) and does not have >>> task to remove Athens style and abstractions. Ideally Sparta will be >>> AthensCairo for bloc. I'm looking forward for your help :) >>> >>> Here are some aspects in AthensCairo that Sparta tries to address in >>> first place: >>> >>>- *Clipping in local coordinates*. It is critical in Bloc. You >>>implemented AthensCairo to have vector based rendering in Morphic and >>> Pharo >>>in general. Morphic lives in global coordinates, so your choice to clip >>> in >>>global coordinate is perfect! At the same time global clipping in bloc >>> adds >>>complexity. Sparta clips always in local coordinates (user space in cairo >>>terminology). >>>- *Clip by arbitrary path*. Athens and AthenCairo expect to see >>>aRectangle as clipping region - your wise choice for morphic. In bloc I >>>would have clipping by arbitrary path. clipBy:during: gets aPath. >>>Rectangle/Color is polymorphic with path/paint in Sparta >>>- *Support of groups*. (maybe user-level aspect? like shadows) >>>Groups are powerful in cairo (do they exist outside of cairo?) and allow >>> to >>>draw both transparent fill and stroke without overlapping using only one >>>path. On class side of BlElement there are examples (exampleCircle) that >>>show such behavior. >>>- *Do not maintain and set pathTransformation before each >>>render-dependent action.* Questionable but what if Canvas will not >>>maintain current state of pathTransform? Instead all transformations can >>> be >>>directly applied on cairo_t using native calls. If there is a need to get >>>actual matrix we can ask cairo directly. From my perspective it >>> simplifies >>>transformation stuff a little bit. >>>- *Benefit from cairo_save and cairo_restore.* AthensCairo maintains >>>state manually by setting transformation matrix and clip. Instead we >>> could >>>save and restore state without caring about clip/matrix which simplifies >>>code. Check SpartaCanvas>>#clipBy:during: >>> >>> >>> Cheers, >>> Alex >>> >>> On Tue, Apr 5, 2016 at 2:12 PM, Igor Stasenko <siguc...@gmail.com> >>> wrote: >>> >>>> >>>> Couple more words about that fill() function abstraction. >>>> Now you probably understand why there's no notion of stroke operation >>>> in Athens. >>>> Because instead of introducing it that way, by adding new kind of a >>>> function >>>> stroke(shape,paint) >>>> from our perspective, it falls into our more generic fill() function, >>>> except that >>>> instead of literally filling the shape we deciding to paint a stroke: >>>> fill(shape, strokePaint). >>>> >>>> As i said, there's nothing that tells that fill() function must affect >>>> only areas enclosed by the shape. >>>> For instance, you could imagine, that i'm in contrary, may want to fill >>>> everything , but the area(s) enclosed by given shape. And that still can be >>>> represented as invocation of our generic fill() function, except that we >>>> will use a different kind of paint, that will fill everything outside >>>> designated region, i.e.: >>>> fill(shape, fillOutsidePaint) >>>> >>>> >>>> >>>> On 5 April 2016 at 14:33, Igor Stasenko <siguc...@gmail.com> wrote: >>>> >>>>> >>>>> >>>>> On 5 April 2016 at 04:00, Ben Coman <b...@openinworld.com> wrote: >>>>> >>>>>> On Tue, Apr 5, 2016 at 2:51 AM, Igor Stasenko <siguc...@gmail.com> >>>>>> wrote: >>>>>> > >>>>>> > Some more bashing today.. (don't take it personal, i may be wrong) >>>>>> > >>>>>> > BlPath hierarchy.. and BlShape. >>>>>> > >>>>>> > Why you redefining what is shape and what is path? >>>>>> > Of course, you are free to do it in Bloc.. >>>>>> > But in terms of Athens, all of BlPath are actually - shapes.. >>>>>> > And BlShape is some kind of encapsulation of shape, paints and >>>>>> transform. >>>>>> > It is a dumb state holder without any extra logic. >>>>>
Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place
On 5 April 2016 at 16:15, Aliaksei Syrel <alex.sy...@gmail.com> wrote: > Hello Igor > > Thanks for extensive design explanation and effort! > Issues you mentioned in previous emails are important and need to be > addressed :) > fill(), stroke() fillPreserve() strokePreserve() need to disappear in the > end. We will come back to them later. > > /me feel happiness :) > Let me tell a few words about Sparta. > Sparta implements Athens interface api (excluding some experimental stuff > to test possible performance boost in a few places) and does not have task > to remove Athens style and abstractions. Ideally Sparta will be AthensCairo > for bloc. I'm looking forward for your help :) > > Here are some aspects in AthensCairo that Sparta tries to address in first > place: > >- *Clipping in local coordinates*. It is critical in Bloc. You >implemented AthensCairo to have vector based rendering in Morphic and Pharo >in general. Morphic lives in global coordinates, so your choice to clip in >global coordinate is perfect! At the same time global clipping in bloc adds >complexity. Sparta clips always in local coordinates (user space in cairo >terminology). > > No, my code is not perfect. Don't say it like that. It was just a mere attempt to marry Morphic with Athens, in order to make things work.. But if it works, it doesn't means it perfect. It just works. I don't need false credit(s) :) Ideally , of course, all clipping should be done in local coordinates. There should be no, or as little as possible things, that require absolute coordinates. And so, i am happy to hear that, and that we are on same side here, i can only welcome any steps towards that direction. > >- *Clip by arbitrary path*. Athens and AthenCairo expect to see >aRectangle as clipping region - your wise choice for morphic. In bloc I >would have clipping by arbitrary path. clipBy:during: gets aPath. >Rectangle/Color is polymorphic with path/paint in Sparta > > That is also a step forward. Ideally it should be possible in Athens as well, to clip using any shape. But.. yeah.. we needed to implement simplest things first, before introducing more. So, ideally what you need is to extend functionality of #clipBy:during: , of AthensCanvas, and allow any shape, not just Rectangle. >- *Support of groups*. (maybe user-level aspect? like shadows) Groups >are powerful in cairo (do they exist outside of cairo?) and allow to draw >both transparent fill and stroke without overlapping using only one path. >On class side of BlElement there are examples (exampleCircle) that show >such behavior. > > Hmm.. That is a higher level/dimension concept. I doubt that graphics engine needs to support it out of the box. Grouping operations is up to the user.. there's no single fixed way how one can group simple operations of fill() function.. and in what order whatever. I do not object that grouping operations are not useful. I just objecting that it should be part of core API. Any kind of grouping is allowed at the user level, so in Bloc you are free to introduce it the way you like or want. I would say more about it, if you would motivate , what you can see, how graphical engine could potentially allow better performance/ease of use in case if it will support groups. For instance , in OpenGL there are a command lists, which you can compile once and then execute it as many time as you want. That is useful in terms that it can prepare a bunch of operations and optimize them for later use. This is basically a simple command pattern, implemented in C :) >From that perspective, if you mean support of groups in that way.. then it is good direction. But if not, then i am not convinced. >- *Do not maintain and set pathTransformation before each >render-dependent action.* Questionable but what if Canvas will not >maintain current state of pathTransform? Instead all transformations can be >directly applied on cairo_t using native calls. If there is a need to get >actual matrix we can ask cairo directly. From my perspective it simplifies >transformation stuff a little bit. > > Review and optimization. I can only welcome that. > >- *Benefit from cairo_save and cairo_restore.* AthensCairo maintains >state manually by setting transformation matrix and clip. Instead we could >save and restore state without caring about clip/matrix which simplifies >code. Check SpartaCanvas>>#clipBy:during: > > Sure, using backend to its full potential is again can be only welcomed. But Cairo is not the only backend for Athens. So, if you can expose such operation at more backend neutral level in Athens, then it is welcome as well. I was thinking about that, but never got my hands to it.. How to expose it in backend
Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place
On 5 April 2016 at 15:58, p...@highoctane.be <p...@highoctane.be> wrote: > Made a quick gist of of this: > https://gist.github.com/philippeback/ef4d128e953de226cf40639641f83e04 > > Thanks. Would be nice if someone with better English than mine skim trough it and fix bad language :) > On Tue, Apr 5, 2016 at 1:33 PM, Igor Stasenko <siguc...@gmail.com> wrote: > >> >> >> On 5 April 2016 at 04:00, Ben Coman <b...@openinworld.com> wrote: >> >>> On Tue, Apr 5, 2016 at 2:51 AM, Igor Stasenko <siguc...@gmail.com> >>> wrote: >>> > >>> > Some more bashing today.. (don't take it personal, i may be wrong) >>> > >>> > BlPath hierarchy.. and BlShape. >>> > >>> > Why you redefining what is shape and what is path? >>> > Of course, you are free to do it in Bloc.. >>> > But in terms of Athens, all of BlPath are actually - shapes.. >>> > And BlShape is some kind of encapsulation of shape, paints and >>> transform. >>> > It is a dumb state holder without any extra logic. >>> > >>> > My rule of thumb: do not produce dumb state holders. They has to be >>> smart, >>> > else it makes no sense in creating separate entity and designating it >>> as >>> > something else than any other bunch of data thrown into single clump, >>> > sitting there deaf, blind, dead and silent until someone else will >>> grab it >>> > somewhere >>> > and start using it for own purpose. >>> > >>> > Sure, i could understand, why you potentially may want such object(s) >>> > around, >>> > but it is not shape anymore and i wouldn't call it like that. Because >>> shape >>> > are shape, and has nothing to do with paints and transform, >>> > it don't knows and don't cares whether it will be filled or stroked or >>> both, >>> > and how many times, and if there will be single paint or thousand. >>> > Such kind of properties is simply orthogonal to what shape existing >>> for, >>> > because it exists only to define geometry. >>> > >>> > I think all of that came from not understanding the roles of objects >>> and how >>> > they interact in Athens. >>> >>> Can you point us to documentation that describes Athen's architecture >>> for these interactions? >>> (sorry I haven't checked class comments, but I'm looking to start with >>> something at higher level anyway) >>> >> >> No, i can't point it out. And you are right , this is nobody else's fault >> than my own. I feel ashamed. Sure how i could demand that people understand >> the concepts, if i didn't explained then anywhere (or if i did, it is not >> in easily reachable place). >> >> So, lets fix that. I will write it down here, and you can pick it up and >> find suitable place for it. >> >> -- >> Basic abstractions behind Athens. >> >> Since Athens is about drawing graphics, we need a media where all drawing >> operations will appear. We call that media a surface. >> The surface is abstract. It can have set dimensions, or don't. We don't >> define if it representing some kind of physical surface (like part of the >> display screen), or how it storing the data inside. We leaving an >> introduction of such details to concrete surface implementation. >> All that matters is that surface is a final target of all our drawing >> operations. >> Therefore, in Athens, a surface is usually a starting point where all >> begins from, and you doing so by creating a specific surface. >> It is surface's responsibility then, to provide user a means how he can >> draw on it, and therefore there is a number of factory methods, that >> allowing you to create a canvas, paints and shapes. All those three are >> specific implementation of AthensCanvas, AthensPaint and AthensShape >> protocols, suitable to be used with specific surface implementation that >> you using. >> >> Canvas. >> Canvas represents a basic drawing context. We don't allow a direct >> operations with surface, but instead we provide a context, that contains >> and carries all information that represents a current stage of drawing >> operations. >> This includes things like, current coordinate transformation(s), >> currently selected paint and shape, and paint mode. >> >> In order to obtain canvas, one must use #drawDuring: message sent to >> surface with block as argument. Th
Re: [Pharo-dev] TxText model
On 5 April 2016 at 04:16, Ben Coman <b...@openinworld.com> wrote: > On Mon, Apr 4, 2016 at 9:49 PM, Igor Stasenko <siguc...@gmail.com> wrote: > > > > > > On 4 April 2016 at 16:32, Thierry Goubier <thierry.goub...@gmail.com> > wrote: > >> > >> > >> > >> 2016-04-04 15:23 GMT+02:00 Igor Stasenko <siguc...@gmail.com>: > >>> > >>> > >>>> > >>> Analogies don't work. Right :) I never used Pillar and have remote > ideas > >>> about what it does or requires. From that perspective you appeal to > wrong > >>> person. On your place i would be asking a guy who knows Pillar innards > about > >>> it. > > Please see... > > [1] > http://esug.org/data/ESUG2015/4%20thursday/1600-1630%20Pilar/Pillar.pdf > > Okay. Now i remember. Yeah, i can easily imagine making a transformer that renders a pillar markup text into TxText instance, by implementing an yet another exporter, like PRTxTextWriter. Certain features would be impossible right now, but for simple docs i guess it may work just fine. > [2] > https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/PillarChap/Pillar.html > > Most (all?) of docs at [3] are done using Pillar... > [3] https://github.com/SquareBracketAssociates > > cheers -ben > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place
Couple more words about that fill() function abstraction. Now you probably understand why there's no notion of stroke operation in Athens. Because instead of introducing it that way, by adding new kind of a function stroke(shape,paint) from our perspective, it falls into our more generic fill() function, except that instead of literally filling the shape we deciding to paint a stroke: fill(shape, strokePaint). As i said, there's nothing that tells that fill() function must affect only areas enclosed by the shape. For instance, you could imagine, that i'm in contrary, may want to fill everything , but the area(s) enclosed by given shape. And that still can be represented as invocation of our generic fill() function, except that we will use a different kind of paint, that will fill everything outside designated region, i.e.: fill(shape, fillOutsidePaint) On 5 April 2016 at 14:33, Igor Stasenko <siguc...@gmail.com> wrote: > > > On 5 April 2016 at 04:00, Ben Coman <b...@openinworld.com> wrote: > >> On Tue, Apr 5, 2016 at 2:51 AM, Igor Stasenko <siguc...@gmail.com> wrote: >> > >> > Some more bashing today.. (don't take it personal, i may be wrong) >> > >> > BlPath hierarchy.. and BlShape. >> > >> > Why you redefining what is shape and what is path? >> > Of course, you are free to do it in Bloc.. >> > But in terms of Athens, all of BlPath are actually - shapes.. >> > And BlShape is some kind of encapsulation of shape, paints and >> transform. >> > It is a dumb state holder without any extra logic. >> > >> > My rule of thumb: do not produce dumb state holders. They has to be >> smart, >> > else it makes no sense in creating separate entity and designating it as >> > something else than any other bunch of data thrown into single clump, >> > sitting there deaf, blind, dead and silent until someone else will grab >> it >> > somewhere >> > and start using it for own purpose. >> > >> > Sure, i could understand, why you potentially may want such object(s) >> > around, >> > but it is not shape anymore and i wouldn't call it like that. Because >> shape >> > are shape, and has nothing to do with paints and transform, >> > it don't knows and don't cares whether it will be filled or stroked or >> both, >> > and how many times, and if there will be single paint or thousand. >> > Such kind of properties is simply orthogonal to what shape existing for, >> > because it exists only to define geometry. >> > >> > I think all of that came from not understanding the roles of objects >> and how >> > they interact in Athens. >> >> Can you point us to documentation that describes Athen's architecture >> for these interactions? >> (sorry I haven't checked class comments, but I'm looking to start with >> something at higher level anyway) >> > > No, i can't point it out. And you are right , this is nobody else's fault > than my own. I feel ashamed. Sure how i could demand that people understand > the concepts, if i didn't explained then anywhere (or if i did, it is not > in easily reachable place). > > So, lets fix that. I will write it down here, and you can pick it up and > find suitable place for it. > > -- > Basic abstractions behind Athens. > > Since Athens is about drawing graphics, we need a media where all drawing > operations will appear. We call that media a surface. > The surface is abstract. It can have set dimensions, or don't. We don't > define if it representing some kind of physical surface (like part of the > display screen), or how it storing the data inside. We leaving an > introduction of such details to concrete surface implementation. > All that matters is that surface is a final target of all our drawing > operations. > Therefore, in Athens, a surface is usually a starting point where all > begins from, and you doing so by creating a specific surface. > It is surface's responsibility then, to provide user a means how he can > draw on it, and therefore there is a number of factory methods, that > allowing you to create a canvas, paints and shapes. All those three are > specific implementation of AthensCanvas, AthensPaint and AthensShape > protocols, suitable to be used with specific surface implementation that > you using. > > Canvas. > Canvas represents a basic drawing context. We don't allow a direct > operations with surface, but instead we provide a context, that contains > and carries all information that represents a current stage of drawing > operations. > This includes things like, current coordinate transformation(s), currently
Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place
On 5 April 2016 at 04:00, Ben Coman <b...@openinworld.com> wrote: > On Tue, Apr 5, 2016 at 2:51 AM, Igor Stasenko <siguc...@gmail.com> wrote: > > > > Some more bashing today.. (don't take it personal, i may be wrong) > > > > BlPath hierarchy.. and BlShape. > > > > Why you redefining what is shape and what is path? > > Of course, you are free to do it in Bloc.. > > But in terms of Athens, all of BlPath are actually - shapes.. > > And BlShape is some kind of encapsulation of shape, paints and transform. > > It is a dumb state holder without any extra logic. > > > > My rule of thumb: do not produce dumb state holders. They has to be > smart, > > else it makes no sense in creating separate entity and designating it as > > something else than any other bunch of data thrown into single clump, > > sitting there deaf, blind, dead and silent until someone else will grab > it > > somewhere > > and start using it for own purpose. > > > > Sure, i could understand, why you potentially may want such object(s) > > around, > > but it is not shape anymore and i wouldn't call it like that. Because > shape > > are shape, and has nothing to do with paints and transform, > > it don't knows and don't cares whether it will be filled or stroked or > both, > > and how many times, and if there will be single paint or thousand. > > Such kind of properties is simply orthogonal to what shape existing for, > > because it exists only to define geometry. > > > > I think all of that came from not understanding the roles of objects and > how > > they interact in Athens. > > Can you point us to documentation that describes Athen's architecture > for these interactions? > (sorry I haven't checked class comments, but I'm looking to start with > something at higher level anyway) > No, i can't point it out. And you are right , this is nobody else's fault than my own. I feel ashamed. Sure how i could demand that people understand the concepts, if i didn't explained then anywhere (or if i did, it is not in easily reachable place). So, lets fix that. I will write it down here, and you can pick it up and find suitable place for it. -- Basic abstractions behind Athens. Since Athens is about drawing graphics, we need a media where all drawing operations will appear. We call that media a surface. The surface is abstract. It can have set dimensions, or don't. We don't define if it representing some kind of physical surface (like part of the display screen), or how it storing the data inside. We leaving an introduction of such details to concrete surface implementation. All that matters is that surface is a final target of all our drawing operations. Therefore, in Athens, a surface is usually a starting point where all begins from, and you doing so by creating a specific surface. It is surface's responsibility then, to provide user a means how he can draw on it, and therefore there is a number of factory methods, that allowing you to create a canvas, paints and shapes. All those three are specific implementation of AthensCanvas, AthensPaint and AthensShape protocols, suitable to be used with specific surface implementation that you using. Canvas. Canvas represents a basic drawing context. We don't allow a direct operations with surface, but instead we provide a context, that contains and carries all information that represents a current stage of drawing operations. This includes things like, current coordinate transformation(s), currently selected paint and shape, and paint mode. In order to obtain canvas, one must use #drawDuring: message sent to surface with block as argument. The given block receives an instance of AthensCanvas as a single parameter. We intentionally enclosing all possible drawing operations within a block to make sure that when we leave, we can safely release all resources that was allocated, required to hold the drawing context state. By exposing it in such form, we also making sure that nothing can alter the surface outside a given block. That way, it gives users a definitive answer, whether he finished drawing operations or not, and if it safe to operate with surface for things like saving it to file, or using it as a source for more complex operations, like acting as a paint to fill area(s) inside another surface etc. Paints and shapes. A starting point is answering a question, how we can represent a simplest, elementary drawing operation on a surface without putting too much constraints. We doing so by postulating that any elementary drawing operation can be expressed by a function: fill(paint, shape) Please, note that 'fill' here is not a literally fill given shape with given paint. We call it 'fill' for simplicity reason. It can anything that altering the surface, but always taking
Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place
On 5 April 2016 at 02:37, Aliaksei Syrel <alex.sy...@gmail.com> wrote: > About hit detection. Idea was to be completely general. And this is the > only approach I found (still bad because uses native calls instead of > athens-like solution) that works with text. Text is also a shape and it's > very cool to be able to detect events inside characters. Imagine morph in > form of huge arbitrary string. > Yes, that would be cool to have. > Current solution does not render, it only sets fill paint and path, then > uses cairo, no need to invent wheel. > Imagine that paint is something fancy, Cairo takes Cairo about special > cases. > This code was born before Cairo came to play. Mind you that Cairo is only one of the potential backends of Athens. It doesn't means that you cannot use feature and invent own wheel. Don't you think i am not hating to reproduce numerical algorithms by myself, if i would be able to use one that already available for use. But that was not the case. So, exposing feature via correct protocol is the way to go. Then when backend provides such feature, one can simply use backed.. and if not - then it will fallback to homemade numerical crunching. And especially that code smells and need a cleanup (not your code, but code in Athens). All i wanna see is exposing feature in nice and consisting way. We all want it to be there. Not just you and me, but whole community does. The rest is a poetry. > Cheers > Alex > On Apr 5, 2016 12:17 AM, "Igor Stasenko" <siguc...@gmail.com> wrote: > >> >> >> On 5 April 2016 at 01:12, Igor Stasenko <siguc...@gmail.com> wrote: >> >>> >>> >>> On 5 April 2016 at 00:51, Andrei Chis <chisvasileand...@gmail.com> >>> wrote: >>> >>> btw, Andrei , if you looking how you can test if point contains shape or >>> not, take a look at AthensCurveFlattener. >>> It converts curved path, that containing Bezier curves (or not) into >>> simple polygonal shape that consists only from a simple lines. >>> Then there AthensPolygonTester, that has the piece you missing: >>> - a small algorithm that can test if given point inside or outside that >>> polygon. >>> >>> Please note that it is simpler even-odd rule algorithm. It not works >>> correctly for all possible cases. >>> >>> There's another algorithm- winding number algorithm, that is much better, >>> but i had to switch to other stuff before were able to get my hands to >>> it. >>> It is more reliable, since it can work for self-intersecting shapes. >>> >>> https://en.wikipedia.org/wiki/Point_in_polygon >>> >>> So, what you need is to wire these things down to Bloc.Then whenever you >>> need to test whether point within shape or not, you can convert any path >>> into polygon and perform the test. And of course, you can cache the results >>> of conversion in order to avoid expensive computations every time you need >>> to perform such tests. Once path is converted, the test is relatively cheap >>> and costs something like O(n), where n is number of line segments. >>> >>> Or maybe, to simplify things, you could extend the shape protocol and >>> introduce #containsPoint: >>> or as variant #containsPoint:ifNotAvailable: >>> so that if shape implements such feature - it can answer true or false, >>> and if not - evaluating a block. So, you don't have to implement all tests >>> for all kinds of shapes that invented or not yet invented in universe. >>> >>> >> Oh, forgot to add, you can look for example how i converting path in >> AthensBezier3Scene class. >> >> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place
On 5 April 2016 at 02:34, Aliaksei Syrel <alex.sy...@gmail.com> wrote: > > Seriously, brute force is synonym of dumb. If you cannot solve the > problem > by anything else than using brute force, then first thing you do, you > leave an extensive comment "sorry guys, this piece stinks, but i was <...> > unable to do any better". > > That is enough, Igor. > Calling other developers or their decisions "dumb" is unacceptable! It is > far way beyond a red line and only shows impoliteness. You are not trying > to constructively criticize but just trolling us. > > Why i should be polite to bad code and bad practices? And have you thought what i should feel , when you using 'perfect' wording for something that not nearly close to perfect? That was insulting. > Here are some basic rules if you want to continue discussion: > > 1) Before "pushing" other people to spend time on you, try to spend your > own. Read previous posts at least in the same thread before writing an > email. Link to bloc build was in the second email but you asked for it 2 or > 3 messages later. > > 2) Don't use "pfff...", "yadda yadda", " pony" or whatever other jargon > in any thread related to bloc. It distracts and shows your disregard to the > reader. > 3) Don't judge others that they don't know or understand something. There > are no stupid people around here. > > 4) Write short but informative emails. We have a lot of other stuff to do. > Everything that you wrote can be expressed using much less amount of > characters. > If you don't have time to read mails, don't read them. Just ignore. Nobody forcing you to to read it. I had to write long, because i need to explain what i don't like and why. Or would it be better for you if i would review the code and just state: - i don't like it, fix it. Leaving you clueless what i don't like and how it should be fixed? Will such brevity help you to fix things? Apparently not. It is quite opposite, because them you can simply ignore it. And if i would do it like that, this is exactly will be disregard to participants of discussion. > 5) First ask why decision was made and only then describe cons and pros. > There is obsolete code in multiple places left because it maybe forgotten > or we realized that it was a mistake but accidentally committed. That > shadow problem was a mistake and big thanks to Glenn who explained and > fixed it in bloc a lot of month ago by using ShadowFilter which is in > another repo for a moment. > > 6) When criticizing try to find and mention also positive desicions. It is > called politeness. > I just want it to see it fixed. Yes, #containsX:Y: works.. but that's far from 'perfect'. Because right now it using a private method of Cairo, bypassing layer of abstraction provided by Athens. So, you need to expose feature in proper way via Athens API.. and then it is perfect. And i didn't mentioned it, because as to me it is obvious. You asking me to be short, but then pointing that i don't mention positive decisions. You can't have both, choose one. >From your side, i don't like to see that on all that mails with many questions, all i got in response it: 'bullshit, it is perfect'. Because it feels like that. If all that i wrote here is bullshit, then fine.. perfect. You don't have to do and worry about anything. > Thanks > Alex > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place
On 5 April 2016 at 00:50, Anonymous <anonymouskni...@hmamail.com> wrote: > As far as I know bloc already has perfect hit detection. In BlPath. What a > dumb state holder! > > Aha, i see - containsX: x Y: y render the path to determine if it contains point or not. Thank you for pointing out! Now i have another reason for yet another rant! Seriously, brute force is synonym of dumb. If you cannot solve the problem by anything else than using brute force, then first thing you do, you leave an extensive comment "sorry guys, this piece stinks, but i was <...> unable to do any better". That at least won't aflame people when they will look at it :) > -- > View this message in context: > http://forum.world.st/bloc-I-do-not-understand-why-some-behavior-is-not-in-the-right-place-tp4888273p4888315.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place
On 5 April 2016 at 01:12, Igor Stasenko <siguc...@gmail.com> wrote: > > > On 5 April 2016 at 00:51, Andrei Chis <chisvasileand...@gmail.com> wrote: > > btw, Andrei , if you looking how you can test if point contains shape or > not, take a look at AthensCurveFlattener. > It converts curved path, that containing Bezier curves (or not) into > simple polygonal shape that consists only from a simple lines. > Then there AthensPolygonTester, that has the piece you missing: > - a small algorithm that can test if given point inside or outside that > polygon. > > Please note that it is simpler even-odd rule algorithm. It not works > correctly for all possible cases. > > There's another algorithm- winding number algorithm, that is much better, > but i had to switch to other stuff before were able to get my hands to it. > It is more reliable, since it can work for self-intersecting shapes. > > https://en.wikipedia.org/wiki/Point_in_polygon > > So, what you need is to wire these things down to Bloc.Then whenever you > need to test whether point within shape or not, you can convert any path > into polygon and perform the test. And of course, you can cache the results > of conversion in order to avoid expensive computations every time you need > to perform such tests. Once path is converted, the test is relatively cheap > and costs something like O(n), where n is number of line segments. > > Or maybe, to simplify things, you could extend the shape protocol and > introduce #containsPoint: > or as variant #containsPoint:ifNotAvailable: > so that if shape implements such feature - it can answer true or false, > and if not - evaluating a block. So, you don't have to implement all tests > for all kinds of shapes that invented or not yet invented in universe. > > Oh, forgot to add, you can look for example how i converting path in AthensBezier3Scene class. > -- > Best regards, > Igor Stasenko. > -- Best regards, Igor Stasenko.
Re: [Pharo-dev] [ bloc ] I do not understand why some behavior is not in the right place
On 5 April 2016 at 00:51, Andrei Chis <chisvasileand...@gmail.com> wrote: btw, Andrei , if you looking how you can test if point contains shape or not, take a look at AthensCurveFlattener. It converts curved path, that containing Bezier curves (or not) into simple polygonal shape that consists only from a simple lines. Then there AthensPolygonTester, that has the piece you missing: - a small algorithm that can test if given point inside or outside that polygon. Please note that it is simpler even-odd rule algorithm. It not works correctly for all possible cases. There's another algorithm- winding number algorithm, that is much better, but i had to switch to other stuff before were able to get my hands to it. It is more reliable, since it can work for self-intersecting shapes. https://en.wikipedia.org/wiki/Point_in_polygon So, what you need is to wire these things down to Bloc.Then whenever you need to test whether point within shape or not, you can convert any path into polygon and perform the test. And of course, you can cache the results of conversion in order to avoid expensive computations every time you need to perform such tests. Once path is converted, the test is relatively cheap and costs something like O(n), where n is number of line segments. Or maybe, to simplify things, you could extend the shape protocol and introduce #containsPoint: or as variant #containsPoint:ifNotAvailable: so that if shape implements such feature - it can answer true or false, and if not - evaluating a block. So, you don't have to implement all tests for all kinds of shapes that invented or not yet invented in universe. -- Best regards, Igor Stasenko.
