Re: [Pharo-dev] is there a way to know when a GC is happening?

[Aliaksei Syrel]

Hi

I wish there was a way to control *when* full GC is allowed to happen. For
example, I would prefer GC to occur while the UI rendering loop is paused
and not in the middle of the frame resulting in sometimes sluggish
animations in the case of large images.

Thank you

On Wed, 9 Sep 2020 at 14:39, Stéphane Ducasse 
wrote:

> Hi
>
> I would to be able to see when an incremental GC is happening.
> is there a way to know when a GC is happening?
>
> S.
>
>
> 
> Stéphane Ducasse
> http://stephane.ducasse.free.fr / http://www.pharo.org
> 03 59 35 87 52
> Assistant: Aurore Dalle
> FAX 03 59 57 78 50
> TEL 03 59 35 86 16
> S. Ducasse - Inria
> 40, avenue Halley
> 
> ,
> Parc Scientifique de la Haute Borne, Bât.A, Park Plaza
> Villeneuve d'Ascq 59650
> France
>
>
>
>
>
>
>
> --
Cheers,
Alex

Re: [Pharo-dev] Fed up

[Aliaksei Syrel]

Hi

Indeed, iterating over a collection using symbols is somewhat ~20% slower :)

Here are some numbers:

aCol := (1 to: 1).


> [ 10 timesRepeat: [ aCol *do: #yourself* ] ] timeToRunWithoutGC / 10.0.
> *"1110.8"*
> [ 10 timesRepeat: [ aCol *do: [ :each | each yourself ]* ] ]
> timeToRunWithoutGC / 10.0. *"898.1"*.


> (1110.8 - 898.1) / 1110.8 * 100 "*19.14836154123154*"


Cheers,
Alex

On Tue, 21 Jan 2020 at 21:11, ducasse  wrote:

> Hi
>
> I’m fed up. Why?
> Because I see lousy code in Pharo and that such lousy code in Pharo is
> slower, and sure that writing a type inferencer
> for pharo will be more complex, and probably will make sista more complex
> too.
>
> I asked the pharo consortium to take a clear position because I want a
> better Pharo not the inverse.
> So what is it.
>
> You can write in your code but not in Pharo.
>
> aCol do: #store
>
> in Pharo we should write
>
> aCol do: [ :each | each store ]
>
> Block argument should be blocks else any static analyser will have to
> check it is a block, it is a symbol, is
> it a RANDOM object that answer value.
>
> Seriously can be not make the life of people doing program analysis
> simpler?
>
> So now if I’m wrong then I will shut up and I’m really pissed that we do
> that without paying attention
> to the consequence.
>
> I asked the consortium to take position and to take action.
> We should have a better code review for REAL.
>
> S.
>
>
>
>

[Pharo-dev] Object>>#pinInMemory performance

[Aliaksei Syrel]

Hello

I stumbled across a performance issue when pinning objects in memory.
Below I have two scripts that pin and unpin a byte array (or any object)
20k times.

The first script pins each time a new byte array:

> [ 2 timesRepeat:  [
>   | array wasPinned |
>   array := ByteArray new.
>   wasPinned := array pinInMemory.
>   array setPinnedInMemory: wasPinned.
> ] ] timeToRunWithoutGC. *"4284"*


while the second one pins the same instance of array:

> array := ByteArray new.
> [ 2 timesRepeat:  [
>| wasPinned |
>wasPinned := array pinInMemory.
>array setPinnedInMemory: wasPinned.
> ] ] timeToRunWithoutGC "*12*"


However, as you can see there is a huge performance difference between
these scripts.

Is it expected or is it a bug? And if it is expected what can be happening
in VM that leads to such huge performance impact? Thanks!

Cheers,
Alex

Re: [Pharo-dev] Debugging GCC code generation

[Aliaksei Syrel]

Hi Pablo,

Wow! Thank you for the detective story :)

Do I understand correctly that the original code causes undefined behavior
and therefore can be changed (or even removed) by the compiler?
(because it returns something that is referencing memory on the stack)

Please keep posting similar things in future! It is very educative :)

Cheers,
Alex


On Wed, 11 Dec 2019 at 17:35, teso...@gmail.com  wrote:

> Hi,
> this mail is related to Pharo because it is knowledge I found
> debugging the build of the VM, but the rest is to document it and
> perhaps someone will found it interesting (also I couldn't find it
> easily using Google). Sorry for the long mail!
>
> The problem
> ==
>
> The following code does not produce good code in 8.3 when using
> optimizations:
>
> long __attribute__ ((noinline)) myFunc(long i, int index){
>long v;
>long x = i >> 3;
>
>v = x;
>return ((int*)())[index];
> }
>
> #include 
>
> int main(){
>
> long i;
> int x;
>
> scanf("%ld", );
> scanf("%d", );
>
> printf("%ld",myFunc(i,x));
> }
>
> Basically, with -02, it generates the following code:
>
> myFunc:
>  movslq %esi, %rsi
>  movslq -8(%rsp,%rsi,4), %rax
>  ret
>
> And with -01 it generates the following code:
>
> myFunc:
>  sarq $3, %rdi
>  movq %rdi, -8(%rsp)
>  movslq %esi, %rsi
>  movslq -8(%rsp,%rsi,4), %rax
>  ret
>
> As you can see, the more optimized version is losing the bit shift (or
> any other operation).
> To detect the problem it was not easy, basically, I have used the
> Pharo Tests to detect the failing function and then to understand the
> generation of code in GCC, we need to debug its generation.
>
> The first snippet is generated using:
>
> gcc -O2 prb.c -S -o prb.s -Wall
>
> and the second using:
>
> gcc -O1 prb.c -S -o prb.s -Wall
>
> The GCC pipeline has different steps, I have centered my self in the
> tree optimizations.
> GCC dumps each of the intermediate states of the compilation, working
> with C like trees. For example to get the optimized version of the
> program, before generating the Assembler we have to do:
>
> gcc -O2 prb.c -S -o prb.s -Wall -fdump-tree-optimized=/dev/stdout
>
> This will generate:
>
> __attribute__((noinline))
> myFunc (long int i, int index)
> {
>   long int v;
>   long unsigned int _1;
>   long unsigned int _2;
>   int * _3;
>   int _4;
>   long int _8;
>
>[local count: 1073741825]:
>   _1 = (long unsigned int) index_7(D);
>   _2 = _1 * 4;
>   _3 =  + _2;
>   _4 = *_3;
>   _8 = (long int) _4;
>   v ={v} {CLOBBER};
>   return _8;
>
> }
>
> This is the optimized SSA (static single assign) version of the
> function (https://gcc.gnu.org/onlinedocs/gccint/SSA.html)
> As you can see in this version the code is already optimized, and our
> operations not correctly generated. We expect to see something like:
>
> __attribute__((noinline))
> myFunc (long int i, int index)
> {
>   long int x;
>   long int v;
>   long unsigned int _1;
>   long unsigned int _2;
>   int * _3;
>   int _4;
>   long int _10;
>
>[local count: 1073741825]:
>   x_6 = i_5(D) >> 3;
>   v = x_6;
>   _1 = (long unsigned int) index_9(D);
>   _2 = _1 * 4;
>   _3 =  + _2;
>   _4 = *_3;
>   _10 = (long int) _4;
>   v ={v} {CLOBBER};
>   return _10;
>
> }
>
> In the first SSA version, we are lacking the shift operation:
>
>   x_6 = i_5(D) >> 3;
>   v = x_6;
>
> So, we need to see in which of the optimizations and transformations
> our code is lost:
> To see all the steps we should execute:
>
> gcc -O2 prb.c -S -o prb.s -Wall -fdump-tree-all
>
> This will generate a lot, really a lot, of files in the same directory.
> They have the name: prb.c.xxx.
> Where xxx is the number of the step, and  is the name of the step.
> Each of the files contains the result of applying the changes, so what
> I have done is looking in binary search where my code was lost.
>
> I have found that the problem was in the first dead code elimination
> step (prb.c.041t.cddce1)
> GCC does not like the crap code that we are writing, as we are copying
> a stack variable and then accessing directly to the memory:
>
> v = x;
> return ((int*)())[index];
>
> So, basically, it was assuming that we were only using v and not x, so
> all the code modifying x is described (this optimization is called
> "dead store code deletion"). Basically tries to remove all the code
> that is affecting stack (temporary) variables that are never used.
>
> I am not sure if this is a bug in GCC, so I will report it. But I have
> fixed the problem writing the code in a proper way.
>
> Sorry again for the long mail, I wanted to store the knowledge and
> propagate it before I eventually will flush it. I like these things,
> but I am not debugging the GCC optimization pipeline all the days.
>
> --
> Pablo Tesone.
> teso...@gmail.com
>
>

Re: [Pharo-dev] Why String do not implement #displayString?

[Aliaksei Syrel]

I had to read more carefully :) Yes, it should be true, but now it is
false, which is a problem.

Cheers,
Alex

On 11 April 2018 at 22:02, Aliaksei Syrel <alex.sy...@gmail.com> wrote:

> Hi,
>
> I am sorry for interrupting this conversation... but
>
> | s |
> s := 'Hello, ''Funny'' World'.
> s displayString = s *"false"* and not true!
>
> Cheers,
> Alex
>
> On 11 April 2018 at 21:53, Stephane Ducasse <stepharo.s...@gmail.com>
> wrote:
>
>> Yes I think that
>>
>> | s |
>> s := 'Hello, ''Funny'' World'.
>> s displayString = s. "true"
>> s printString = s. "false"
>>
>> is ok and widgets should use displayString.
>>
>> Stef
>>
>>
>> On Tue, Apr 10, 2018 at 5:28 PM, Esteban A. Maringolo
>> <emaring...@gmail.com> wrote:
>> > Isn't #displayString implemented in terms of #displayOn: the same way
>> > #printString is implemented in terms of "printOn:"?
>> >
>> > And in the case of String #displayString should return the receiver (it
>> > is, self), so the following should be true.
>> >
>> > | s |
>> > s := 'Hello, ''Funny'' World'.
>> > s displayString = s. "true"
>> > s printString = s. "false"
>> >
>> > Regards,
>> >
>> >
>> > On 10/04/2018 12:21, Denis Kudriashov wrote:
>> >> Hi.
>> >>
>> >> According to the comment of #displayString it should be used as default
>> >> textual representation of objects in the UI:
>> >>
>> >> "While printString is about to give a detailled information about
>> an
>> >> object, displayString is a message that should return a short
>> >> string-based representation to be used by list and related UI
>> >> frameworks. By default, simply return printString."
>> >> "asString should not be implemented in Object, and kept for
>> >> conversion between strings, symbols, text and characters."
>> >>
>> >> But String itself does not respect this message:
>> >>
>> >> 'some string' displayString " ==> '''someString''' "
>> >>
>> >>
>> >> Is it bug? Or is there any reason for this?
>> >>
>> >> Best regards,
>> >> Denis
>> >
>> > --
>> > Esteban A. Maringolo
>> >
>>
>>
>

Re: [Pharo-dev] Why String do not implement #displayString?

[Aliaksei Syrel]

Hi,

I am sorry for interrupting this conversation... but

| s |
s := 'Hello, ''Funny'' World'.
s displayString = s *"false"* and not true!

Cheers,
Alex

On 11 April 2018 at 21:53, Stephane Ducasse  wrote:

> Yes I think that
>
> | s |
> s := 'Hello, ''Funny'' World'.
> s displayString = s. "true"
> s printString = s. "false"
>
> is ok and widgets should use displayString.
>
> Stef
>
>
> On Tue, Apr 10, 2018 at 5:28 PM, Esteban A. Maringolo
>  wrote:
> > Isn't #displayString implemented in terms of #displayOn: the same way
> > #printString is implemented in terms of "printOn:"?
> >
> > And in the case of String #displayString should return the receiver (it
> > is, self), so the following should be true.
> >
> > | s |
> > s := 'Hello, ''Funny'' World'.
> > s displayString = s. "true"
> > s printString = s. "false"
> >
> > Regards,
> >
> >
> > On 10/04/2018 12:21, Denis Kudriashov wrote:
> >> Hi.
> >>
> >> According to the comment of #displayString it should be used as default
> >> textual representation of objects in the UI:
> >>
> >> "While printString is about to give a detailled information about an
> >> object, displayString is a message that should return a short
> >> string-based representation to be used by list and related UI
> >> frameworks. By default, simply return printString."
> >> "asString should not be implemented in Object, and kept for
> >> conversion between strings, symbols, text and characters."
> >>
> >> But String itself does not respect this message:
> >>
> >> 'some string' displayString " ==> '''someString''' "
> >>
> >>
> >> Is it bug? Or is there any reason for this?
> >>
> >> Best regards,
> >> Denis
> >
> > --
> > Esteban A. Maringolo
> >
>
>

Re: [Pharo-dev] DateAndTime Offset Bug Proposal

[Aliaksei Syrel]

Must watch :)

The Problem with Time & Timezones - Computerphile
https://www.youtube.com/watch?v=-5wpm-gesOY

On 9 April 2018 at 17:26, Sven Van Caekenberghe  wrote:

>
>
> > On 9 Apr 2018, at 15:19, Sean P. DeNigris  wrote:
> >
> > Max Leske wrote
> >> Assuming UTC is probably just as wrong as assuming the local time zone.
> >
> > I'll modify your statement slightly. "Assuming UTC is */almost/* as
> wrong as
> > assuming the local time zone."
> >
> > I've never seemed to be able to drive the essential point home when these
> > discussions have come up. Beyond all the wider issues, there is a bug,
> plain
> > and simple: The offset of `'1/1/1990' asDate`, considering that you mean
> > local time, is still not guaranteed to be the current local offset of the
> > image, which is how we set it by default. That only makes sense if the
> > historical date in question was in the same state of DST as the current
> > image. For example, the historical date above is in winter, so if I eval
> > that code in summer, it will /always/ give the objectively wrong offset.
> >
> > What I'm proposing is not a cure all, but a slightly-better way that
> fixes
> > this bug by giving users consistent behavior that they may not want
> instead
> > of inconsistent and often wrong behavior that they may not want.
>
> Sean,
>
> You are right, the current system cannot be fixed. It only knows about the
> current timezone's offset (via the OS), not about historical offsets. And
> it wrongly uses that offset because it does not know better.
>
> Neither
>
>   '1/1/1990' asDate.
>
> nor
>
>   Date today.
>
> can work without the context of a precise timezone. It is even relatively
> pointless to remember offsets without remembering timezones. You simply
> need a precise reference into the transitions database.
>
> New York is 5 hours behind UTC in winter.
>
> Question 1: When (in absolute UTC time) was the beginning of the 1st day
> of January in 1990 in New York's local time, when we express the date in
> UTC ?
>
> (ZTimezone id: 'America/New_York') gmtToLocal: (ZTimestamp @ '1990/01/01').
>
>   => "1989-12-31T19:00:00Z"
>
> So when the UTC day of January 1st 1990 starts, New York local time is
> still 5 hours behind.
>
> Question 2: When (in absolute UTC time) was the beginning of the 1st day
> of January in 1990 in UTC time, when we express the date locally ?
>
> (ZTimezone id: 'America/New_York') localToGmt: (ZTimestamp @ '1990/01/01').
>
>   => "1990-01-01T05:00:00Z"
>
> So when the New York day of January 1st 1990 starts, UTC time is already 5
> hours ahead.
>
> Note that the question 'When does January 1st 1990 start in any timezone,
> when expressed in that timezone, is of course a constant, midnight'.
>
>
> I think that making Date always UTC will probably not help, because you
> will want to be able to move between timezones. I guess the only solution
> is to add a class like ZTimezone (which has no dependencies).
>
>
> Sven
>
> > -
> > Cheers,
> > Sean
> > --
> > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.
> html
> >
>
>
>

Re: [Pharo-dev] call for help: answer on HN :)

[Aliaksei Syrel]

Hi

Here is a link to a report about their experience with Pharo:
https://gitlab.fit.cvut.cz/taibrmar/sokoban-using-bloc

There definitely exist things that should be improved. It is a pity when
tiny “minor” issues leave such an unpleasant aftertaste.

Anyway, there are lovers and haters of every language. Some people even
give dislikes to videos on YouTube that show how veterinarians heal cats...

All the best
Alex

On Sat, 7 Apr 2018 at 17:27, Stephane Ducasse 
wrote:

> I tend to not care about people pissing on me via a pseudo. This is
> too easy and too microscopic to have any value.
> Thanks Philippe, Luke and Ben because you use your real names.
>
> On Thu, Apr 5, 2018 at 2:07 PM, Esteban Lorenzano 
> wrote:
> > Hi,
> >
> > yesterday someone posted an article on HN about the Pharo MOOC and there
> has
> > been some negative posts there.
> > I would like to call people who can have the time to answer there and
> help
> > to explain better and also contribute to contest that FUD someones (we
> know
> > who they are… sames as always) are spreading.
> >
> > here the link : https://news.ycombinator.com/item?id=16754872
> >
> > (this is not loosing time, people searching for Pharo will likely see
> this
> > kind of messages… at least we need to offer our point of view)
> >
> > cheers!
> > Esteban
>
> --
Cheers,
Alex

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

[Aliaksei Syrel]

Hi,

Bintray has 6 months upload limit for the same release. Uploading of a new
binary to #development release becomes impossible after 6 month since
creation of that release.
I have to delete and re-create releases once in a while...

Cheers,
Alex

On 1 April 2018 at 12:49, Esteban Lorenzano  wrote:

> hi,
>
> On 31 Mar 2018, at 22:42, Alistair Grant  wrote:
>
> Hi Pablo & Eliot,
>
> On 31 March 2018 at 20:49, Eliot Miranda  wrote:
>
> Hi Pablo,
>
> On Sat, Mar 31, 2018 at 10:19 AM, teso...@gmail.com 
> wrote:
>
>
> Hi,
> I am taking the VM from the latest VM in
> http://files.pharo.org/get-files/70/ (the one downloaded by the get pharo
> scripts, I believe is
> http://files.pharo.org/get-files/70/pharo-mac-latest.zip)
> The output of version in the VM is:
>
> 5.0 5.0.201803151936 Mac OS X built on Mar 15 2018 23:30:17 UTC Compiler:
> 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31) [Production Spur VM]
>
> CoInterpreter VMMaker.oscog-eem.2347 uuid:
> 062614a7-e3da-4b30-997a-9568911b9ff5 Mar 15 2018
>
> StackToRegisterMappingCogit VMMaker.oscog-eem.2347 uuid:
> 062614a7-e3da-4b30-997a-9568911b9ff5 Mar 15 2018
>
> VM: 201803151936 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
> Date: Thu Mar 15 20:36:43 2018 +0100 $
>
> Plugins: 201803151936
> https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
>
>
> I don't know if this information helps you to know the specific commit,
> but please feel free to tell me how I can get the exact commit from the VM.
> Or where to get other VMs to check the error.
>
>
>
> The best one can do is either
> - running the VM executable from the command line using --version
> - via the System Reporter
>
> Alas git doesn't help here.  Unlike many other scc systems git doesn't
> provide a metalanguage to embed the current commit id into source.  The
> best
> we have is the time stamp and as we can see the granularity isn't good
> enough when things are changing quickly.
>
>
> git doesn't provide a substitution mechanism like sccs, but the script
> we have that embeds the date can just as easily embed the hash.  In
> .git_filters/RevDateURL.smudge there's a line that retrieves the
> commit date from git:
>
> $date = `git log --format=%ad -1`;
>
> to get the (short) hash we can simply add:
>
> $shorthash = `git log --format=%h -1`;
>
> The string substitution can then proceed as for the date.
>
> I think it would be worthwhile having both the date and hash in the
> --version info.
>
> I'm happy to add this in and update the --version output if there's
> general agreement.
>
>
>
> As Alistair says, the issue is fixed in the VMMaker.oscog package commit
> VMMaker.oscog-eem.2359, which is
>
> commit 1f0a7da9d4e8dcf4cdfac07014decdadac6937bb
> Author: Eliot Miranda 
> Date:   Thu Mar 15 18:09:12 2018 -0700
>
>
>
> Which unfortunately is 1 commit after the version you have.
>
> There appears to be a separate problem that MacOS VMs aren't being
> uploaded to files.pharo.org, so while running the VM through the Pharo
> automated test suite and bootstrap process is a great idea, right now
> we need to wait for an updated VM for MacOS. :-(.
>
>
> I just figured out last green build of Cog was 16 days ago so is correct
> (and not an error) that no mac build is being copied: there is no build
> since linux build failed and then no mac build was ran.
> Is not a problem about mac files copied to pharo file server but a general
> one (but that does not explains the bintray problem, since last upload
> there is from 8/03 and there was at least one successful build after)
>
> cheers,
> Esteban
>
>
>
> Cheers,
> Alistair
>
>
>
>CogVM source as per VMMaker.oscog-eem.2359
>
>Cogits:
>Fix regression introduced in VMMaker.oscog-eem.2333 or thereabouts when
> improving comoilation breakpoint.  maybeSelectorOfMethod can answer nil so
> a
> guard is needed.
>
> I'm sorry but the crash.dmp doesn't appear to include the VMMaker.oscog
> commit.  I thought it did.  I'll fix this.
>
>
> Cheers,
> Pablo
>
> On Sat, Mar 31, 2018 at 6:53 PM, Alistair Grant 
> wrote:
>
>
> Hi Pablo,
>
> On 31 March 2018 at 18:36, teso...@gmail.com  wrote:
>
> Hi Everyone,
>  I have created the PR in Pharo, so the CI runs the bootstrap with the
> latest VM (March 15th).
> Running the process fails during execution of the tests in 32bits OSX.
> It crashes the VM with a segmentation fault.
> I could reproduce the crash, running the tests from the command line,
> and
> also running OCBytecodeGeneratorTest test.
>
>
>
> There were several VMs built on / around the 15th.  Would you mind
> letting me know the commit hash as Eliot fixed this particular problem
> about then.
>
> I tested 43a2f5c.
>
> Thanks,
> Alistair
>
>
>
>
> I am attaching the crash.dmp with both executions (from the commandLine
> and
> headful), both are in the same point.
>
> Cheers,
> Pablo

Re: [Pharo-dev] Roadmap to Pharo 7 Release

[Aliaksei Syrel]

Hi,

btw, there is an interesting opened issue on Cargo's github page:
https://github.com/demarey/cargo/issues/32

I wanted to let you know that the Rust programming language ships with a
> package manager that is also called Cargo, which is a trademarked part of
> the project. There definitely seems to be scope for confusion around the
> name. Can we work together to figure something out?


It is opened by Aaron Turon, Mozilla developer.

Any thoughts?

Cheers,
Alex

On 27 March 2018 at 20:29, Peter Uhnák  wrote:

> So I take it Cargo will not be in P7? (Assuming Cargo is still being
> developed, which it currently isn't.)
>
> Thanks,
> Peter
>
> On Tue, Mar 27, 2018 at 8:11 PM, Esteban Lorenzano 
> wrote:
>
>> still we have to release iceberg 0.7 then we’ll see how we are there.
>> and still we have to make a 64bit windows VM+image that works for us.
>> and we still need to fix that annoying debug blocking all bug
>> and of course, we have some leaks we still need to solve.
>>
>> I think all the other issues are covered (I need to check and I can’t
>> right now… but I have that feeling).
>>
>> cheers,
>> Esteban
>>
>>
>>
>> > On 27 Mar 2018, at 19:47, Sean P. DeNigris 
>> wrote:
>> >
>> > Does a high level overview exist of what still has to be done? Do we
>> expect
>> > any more potentially-disruptive changes or are we in/near the
>> stabilization
>> > phase?
>> >
>> >
>> >
>> > -
>> > Cheers,
>> > Sean
>> > --
>> > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.ht
>> ml
>> >
>>
>>
>>
>

Re: [Pharo-dev] Bloc: Simulating "Worlds"

[Aliaksei Syrel]

"a reply"

^^ here you go, Sean :)

P.S. I will reply here with an example when it is done. We need to simulate
bloc spaces exactly as you described to record gifs and videos without
frame drop at 60fps.

Cheers,
Alex

On 27 March 2018 at 19:36, Sean P. DeNigris  wrote:

> Sean P. DeNigris wrote
> > Sean P. DeNigris wrote
> >> Looks like it's time for my annual Bloc Dream check in ha ha!
> > [crickets chirping]…
> > One year too many?
>
> I committed a Bloc fix. Does that earn me a reply? ;-)
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>

Re: [Pharo-dev] Change Pharo window icon

[Aliaksei Syrel]

Hi Eliot,

I thought Vincent wants to change Pharo main window icon (image).

> I would like to know how to change the main Pharo window icon.


The fact that he mentioned an ability to change window's title from inside
of the running image suggested me that he actually wants to change an icon
at runtime too.

> DisplayScreen class  >> primitiveWindowTitle:string:


I may be wrong :) But in any case it would be nice to be able to change
window icon from the image.

Cheers,
Alex

On 3 February 2018 at 17:01, Eliot Miranda <eliot.mira...@gmail.com> wrote:

> Hi Aliaksei,
>
> On Feb 3, 2018, at 4:30 AM, Aliaksei Syrel <alex.sy...@gmail.com> wrote:
>
> Hi
>
> Since Pharo uses sdl2 (or should use)
> https://wiki.libsdl.org/SDL_SetWindowIcon
>
>
> Hang on.  Changing a window's icon is not at all the same as changing the
> VM's icon.  Which are we talking about here?  I thought we were talking
> about changing the VM icon.
>
>
> Alex
>
> On Sat, 3 Feb 2018 at 13:27, philippe.b...@highoctane.be <
> philippe.b...@gmail.com> wrote:
>
>> Well, Windows is still Windows at the core.
>>
>> Even some Windows 2.0 books can provide insights into its working
>> principles that are hard to find these days.
>>
>> Anyway, I remember that there is a way to change the icon at runtime but
>> not when listing the exe. Hence Resource editor.
>>
>> Phil
>>
>> On Feb 2, 2018 21:17, "Stephane Ducasse" <stepharo.s...@gmail.com> wrote:
>>
>>> Yes I did that when I was at University. So clearly dated.
>>>
>>>
>>> On Fri, Feb 2, 2018 at 8:40 PM, p...@highoctane.be <p...@highoctane.be>
>>> wrote:
>>> > For Windows one can change it using a resource editor.
>>> >
>>> > http://www.angusj.com/resourcehacker/
>>> >
>>> > Phil
>>> >
>>> > On Feb 2, 2018 20:33, "Stephane Ducasse" <stepharo.s...@gmail.com>
>>> wrote:
>>> >>
>>> >> Would it be possible to change the icon without having to compile a
>>> new
>>> >> VM?
>>> >> To me the current setup looks so monolithic and dated.
>>> >> I would expect that somebody can deploy a application with its own
>>> >> logo by just providing some new resources.
>>> >>
>>> >> Stef
>>> >>
>>> >> On Wed, Jan 31, 2018 at 11:17 PM, Eliot Miranda <
>>> eliot.mira...@gmail.com>
>>> >> wrote:
>>> >> > Hi Vincent,
>>> >> >
>>> >> > On Wed, Jan 31, 2018 at 12:07 PM, <vincent.blond...@lamresearch.com
>>> >
>>> >> > wrote:
>>> >> >>
>>> >> >> Hi,
>>> >> >>
>>> >> >> I would like to know how to change the main Pharo window icon. I
>>> saw
>>> >> >> that
>>> >> >> there is a primitive for the title:
>>> >> >> DisplayScreen class  >> primitiveWindowTitle:string: ; primitive:
>>> >> >> 'primitiveHostWindowTitle' module:'HostWindowPlugin'
>>> >> >> but I cannot find one for the icon.
>>> >> >> Should another primitive need to be implemented?
>>> >> >
>>> >> >
>>> >> > The icon is baked into the VM executable.  So to change it one has
>>> to
>>> >> > build
>>> >> > a VM with a different icon.
>>> >> >
>>> >> > On Windows it is in
>>> >> > {build.win32x86,build.win64x64}/pharo.cog.spur/Pharo.ico
>>> >> > and the file that specifies to use Pharo.ico is
>>> >> > {build.win32x86,build.win64x64}/pharo.cog.spur/Pharo.rc
>>> >> >
>>> >> > On Mac OS X it is in
>>> >> > platforms/iOS/vm/OSX/Pharo.icns
>>> >> > (alongside three others such as PharoImage.icns)
>>> >> > and the file that specifies to use Pharo.icns is
>>> >> > {build.macos32x86,build.macos64x64}/pharo.cog.spur/Makefile
>>> >> > in setting the VM variable.  The file that associates the other
>>> icons
>>> >> > with
>>> >> > specific file types is
>>> >> > platforms/iOS//vm/OSX/Pharo-Info.plist
>>> >> >
>>> >> > If you're changing the Pharo icon let me suggest you update the icon
>>> >> > files
>>> >> > themselves in the opensmalltalk-vm source tree.
>>> >> >
>>> >> > If you're creating a new variant of the VM for some new purpose
>>> (say a
>>> >> > special Lam VM) then let me suggest you add the icons to the
>>> >> > opensmalltalk-vm source tree, creating special build directories for
>>> >> > these
>>> >> > VMs, such as {build.macos32x86,build.macos6
>>> 4x64}/lam.pharo.cog.spur/
>>> >> >
>>> >> > If you want to do this privately, then take either of the approaches
>>> >> > above
>>> >> > and simply don't publish the edits.  You can write a script that
>>> takes
>>> >> > an
>>> >> > updated checked-out opensmalltalk-vm source tree and edits it with
>>> files
>>> >> > from a specific repository.  I have such scripts and can help you
>>> with
>>> >> > them.
>>> >> > Hint, pax is a very convenient directory hierarchy copying tool
>>> >> > available at
>>> >> > least on Mac OS X.  pax -rwlk will copy the trees under a sequence
>>> of
>>> >> > directories into their corresponding places in a target tree.
>>> >> >
>>> >> >>
>>> >> >> Thanks!
>>> >> >>
>>> >> >> Vincent
>>> >> >>
>>> >> >>
>>> >> >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > _,,,^..^,,,_
>>> >> > best, Eliot
>>> >>
>>> >
>>>
>>> --
> Cheers,
> Alex
>
>

Re: [Pharo-dev] Change Pharo window icon

[Aliaksei Syrel]

Hi

Since Pharo uses sdl2 (or should use)
https://wiki.libsdl.org/SDL_SetWindowIcon

Alex

On Sat, 3 Feb 2018 at 13:27, philippe.b...@highoctane.be <
philippe.b...@gmail.com> wrote:

> Well, Windows is still Windows at the core.
>
> Even some Windows 2.0 books can provide insights into its working
> principles that are hard to find these days.
>
> Anyway, I remember that there is a way to change the icon at runtime but
> not when listing the exe. Hence Resource editor.
>
> Phil
>
> On Feb 2, 2018 21:17, "Stephane Ducasse"  wrote:
>
>> Yes I did that when I was at University. So clearly dated.
>>
>>
>> On Fri, Feb 2, 2018 at 8:40 PM, p...@highoctane.be 
>> wrote:
>> > For Windows one can change it using a resource editor.
>> >
>> > http://www.angusj.com/resourcehacker/
>> >
>> > Phil
>> >
>> > On Feb 2, 2018 20:33, "Stephane Ducasse" 
>> wrote:
>> >>
>> >> Would it be possible to change the icon without having to compile a new
>> >> VM?
>> >> To me the current setup looks so monolithic and dated.
>> >> I would expect that somebody can deploy a application with its own
>> >> logo by just providing some new resources.
>> >>
>> >> Stef
>> >>
>> >> On Wed, Jan 31, 2018 at 11:17 PM, Eliot Miranda <
>> eliot.mira...@gmail.com>
>> >> wrote:
>> >> > Hi Vincent,
>> >> >
>> >> > On Wed, Jan 31, 2018 at 12:07 PM, 
>> >> > wrote:
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> I would like to know how to change the main Pharo window icon. I saw
>> >> >> that
>> >> >> there is a primitive for the title:
>> >> >> DisplayScreen class  >> primitiveWindowTitle:string: ; primitive:
>> >> >> 'primitiveHostWindowTitle' module:'HostWindowPlugin'
>> >> >> but I cannot find one for the icon.
>> >> >> Should another primitive need to be implemented?
>> >> >
>> >> >
>> >> > The icon is baked into the VM executable.  So to change it one has to
>> >> > build
>> >> > a VM with a different icon.
>> >> >
>> >> > On Windows it is in
>> >> > {build.win32x86,build.win64x64}/pharo.cog.spur/Pharo.ico
>> >> > and the file that specifies to use Pharo.ico is
>> >> > {build.win32x86,build.win64x64}/pharo.cog.spur/Pharo.rc
>> >> >
>> >> > On Mac OS X it is in
>> >> > platforms/iOS/vm/OSX/Pharo.icns
>> >> > (alongside three others such as PharoImage.icns)
>> >> > and the file that specifies to use Pharo.icns is
>> >> > {build.macos32x86,build.macos64x64}/pharo.cog.spur/Makefile
>> >> > in setting the VM variable.  The file that associates the other icons
>> >> > with
>> >> > specific file types is
>> >> > platforms/iOS//vm/OSX/Pharo-Info.plist
>> >> >
>> >> > If you're changing the Pharo icon let me suggest you update the icon
>> >> > files
>> >> > themselves in the opensmalltalk-vm source tree.
>> >> >
>> >> > If you're creating a new variant of the VM for some new purpose (say
>> a
>> >> > special Lam VM) then let me suggest you add the icons to the
>> >> > opensmalltalk-vm source tree, creating special build directories for
>> >> > these
>> >> > VMs, such as {build.macos32x86,build.macos64x64}/lam.pharo.cog.spur/
>> >> >
>> >> > If you want to do this privately, then take either of the approaches
>> >> > above
>> >> > and simply don't publish the edits.  You can write a script that
>> takes
>> >> > an
>> >> > updated checked-out opensmalltalk-vm source tree and edits it with
>> files
>> >> > from a specific repository.  I have such scripts and can help you
>> with
>> >> > them.
>> >> > Hint, pax is a very convenient directory hierarchy copying tool
>> >> > available at
>> >> > least on Mac OS X.  pax -rwlk will copy the trees under a sequence of
>> >> > directories into their corresponding places in a target tree.
>> >> >
>> >> >>
>> >> >> Thanks!
>> >> >>
>> >> >> Vincent
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > _,,,^..^,,,_
>> >> > best, Eliot
>> >>
>> >
>>
>> --
Cheers,
Alex

Re: [Pharo-dev] Implementors of margins in GLMRubScrolledTextBrick

[Aliaksei Syrel]

Hi,

GLMRubScrolledTextBrick is a wrapper around RubScrollTextMorph.
I see that it is a common practice in Pharo to implement decorator /
wrapper pattern using doesNotUnderstand:.

Reference:
  - AthensWrappedWorldDisplay
  - DictionaryValueHolder
  - MorphicTreeAdapter
  - RubEditingArea
  - RubParagraphDecorator

  - RTShapeBuilder
  - RTShowLabel

Is there a better way to implement a decorator or a wrapper around the
object with many api methods rather then doesNotUnderstand:?

Cheers,
Alex

On 9 December 2017 at 17:45, Henrik-Nergaard  wrote:

> >>GLMRubScrolledTextBrick>>withoutMargins uses self margins: but I
> cannot find the method.
> This is because it is implemented in RubScrollTextMorph.
> GLMRubScrolledTextBrick implements #doesNotUnderstand: to send it to the
> rubric object.
> see:
> https://pharo.fogbugz.com/f/cases/17888/GLMRubScrolledTextBr
> ick-relies-on-dnu-delegation
>
> Best regards,
> Henrik
>
>
>
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>

Re: [Pharo-dev] Bloc Feedback

[Aliaksei Syrel]

I forgot to mention that "BlPostAction" is a one time action - it
disappears once done :)

Cheers,
Alex

On 2 December 2017 at 17:26, Aliaksei Syrel <alex.sy...@gmail.com> wrote:

> Hi,
>
> An object that is called now "Animation" in Bloc is not necessarily bound
> to the visual element.
> The correct name for the root class of "BlBaseAnimation" should be
> "BlPostAction" - a valuable that is guaranteed to be evaluated in the
> beginning of every frame before anything else. We have already a deferred
> action but they are only evaluated when there is enough time between frames.
> "BlBaseAnimation" should be renamed to something line "BlElementAnimation"
> that is guaranteed to be bound to a visual element and stops itself if
> element is no more in the scene graph *by checking that explicitly before
> doing every animation step*.
>
> Cheers,
> Alex
>
> On 2 December 2017 at 16:35, Sean P. DeNigris <s...@clipperadams.com>
> wrote:
>
>> Aliaksei Syrel wrote
>> > ...
>> >  Also, what is the lifetime of an infinite animation?
>> > ...
>> > Do you have any particular use-case for animations?
>>
>> I hacked together a simplified stepping animation (may not be in the right
>> place in the class hierarchy). Here's a pull request to discuss
>> https://github.com/pharo-graphics/Bloc/pull/37
>>
>>
>>
>> -
>> Cheers,
>> Sean
>> --
>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>>
>>
>

Re: [Pharo-dev] Bloc Feedback

[Aliaksei Syrel]

Hi,

An object that is called now "Animation" in Bloc is not necessarily bound
to the visual element.
The correct name for the root class of "BlBaseAnimation" should be
"BlPostAction" - a valuable that is guaranteed to be evaluated in the
beginning of every frame before anything else. We have already a deferred
action but they are only evaluated when there is enough time between frames.
"BlBaseAnimation" should be renamed to something line "BlElementAnimation"
that is guaranteed to be bound to a visual element and stops itself if
element is no more in the scene graph *by checking that explicitly before
doing every animation step*.

Cheers,
Alex

On 2 December 2017 at 16:35, Sean P. DeNigris <s...@clipperadams.com> wrote:

> Aliaksei Syrel wrote
> > ...
> >  Also, what is the lifetime of an infinite animation?
> > ...
> > Do you have any particular use-case for animations?
>
> I hacked together a simplified stepping animation (may not be in the right
> place in the class hierarchy). Here's a pull request to discuss
> https://github.com/pharo-graphics/Bloc/pull/37
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>

Re: [Pharo-dev] Bloc Feedback

[Aliaksei Syrel]

Hi Sean,

Yes, after animation is stopped it is removed from the animation manager
and if referenced weakly should be garbage collected.
Otherwise it is a bug :)

Cheers,
Alex

On 2 December 2017 at 04:48, Sean P. DeNigris <s...@clipperadams.com> wrote:

> Aliaksei Syrel wrote
> >> So one would change the `loop: 1` in your example to `beInfinite`?
> > ...
> >  Also, what is the lifetime of an infinite animation?
> >
> >
> > It can only be stopped by sending #stop to it.
>
> Is holding it weakly from the element and sending #stop enough for the
> animation to be garbage collected?
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>

Re: [Pharo-dev] Bloc and Gestures

[Aliaksei Syrel]

Hi Sean,

The main problem of gestures is that they can only theoretically work with
OS-Window (SDL2 or other windowing library).
With morphic ​I can not even find how to add support of horizontal
scrolling using touchpad...

For this reason those gestures are hierarchy placeholder and are not used
anywhere.
As for ETA ... 3 months maybe :) I think we will work on gestures as soon
as bloc will officially supports SDL2 windows.

Cheers,
Alex

Re: [Pharo-dev] Is SmalltalkCI working for Pharo projects?

[Aliaksei Syrel]

Hi,

We have the same problem. It infinitly loops on coverage and says "out of
memory" in the end.

Cheers,
Alex

On Nov 26, 2017 2:18 PM, "Gabriel Cotelli"  wrote:

I'm pretty sure are not my changes, because in one of the pull requests I
just added Pharo 6.1 as a tested platform but no code was changed and I'm
getting the same error on all the platforms ( https://github.com/ba-st/Buoy/
pull/18 ).

Fabio: maybe something changed in SmalltalkCI triggering this error? From
the logs seems that it's something related to coverage doing an infinite
loop:

IdentityDictionary(HashedCollection)>findElementOrNil: 0xc089d50: a(n)
IdentityDictionary

0xfff87dd4 M IdentityDictionary(Dictionary)>at:ifAbsent: 0xc089d50: a(n)
IdentityDictionary

0xfff87df4 M RGMethodDefinition(RGDefinition)>annotationNamed:ifAbsent:
0xc083658: a(n) RGMethodDefinition

0xfff87e14 M RGMethodDefinition(RGDefinition)>environment 0xc083658: a(n)
RGMethodDefinition

0xfff87e30 M RGMethodDefinition(RGDefinition)>rootEnvironment 0xc083658:
a(n) RGMethodDefinition

0xfff87e48 M RGMethodDefinition(RGElementDefinition)>realParent 0xc083658:
a(n) RGMethodDefinition

0xfff87e60 M RGMethodDefinition(RGElementDefinition)>realClass 0xc083658:
a(n) RGMethodDefinition

0xfff87e78 M RGMethodDefinition(RGElementDefinition)>actualClass 0xc083658:
a(n) RGMethodDefinition

0xfff87e90 M TestCoverage>uninstall 0xc082400: a(n) TestCoverage

0xfff87ea8 M TestCoverage>run:with:in: 0xc082400: a(n) TestCoverage

0xfff87ecc M ByteString(String)>asSymbol 0x9300760: a(n) ByteString

0xfff87ef0 M SystemDictionary>classOrTraitNamed: 0x9895350: a(n)
SystemDictionary

0xfff87f0c M SystemDictionary>classNamed: 0x9895350: a(n) SystemDictionary

0xfff87f28 M RGMethodDefinition(RGElementDefinition)>realParent 0xc083658:
a(n) RGMethodDefinition

0xfff87f40 M RGMethodDefinition(RGElementDefinition)>realClass 0xc083658:
a(n) RGMethodDefinition

0xfff87f58 M RGMethodDefinition(RGElementDefinition)>actualClass 0xc083658:
a(n) RGMethodDefinition

0xfff87f70 M TestCoverage>uninstall 0xc082400: a(n) TestCoverage

0xfff87f88 M TestCoverage>run:with:in: 0xc082400: a(n) TestCoverage

0xfff87fac M ByteString(String)>asSymbol 0x9300780: a(n) ByteString

0xfff87fd0 M SystemDictionary>classOrTraitNamed: 0x9895350: a(n)
SystemDictionary

0xfff87fec M SystemDictionary>classNamed: 0x9895350: a(n) SystemDictionary

0xfff88008 M RGMethodDefinition(RGElementDefinition)>realParent 0xc083658:
a(n) RGMethodDefinition

0xfff88020 M RGMethodDefinition(RGElementDefinition)>realClass 0xc083658:
a(n) RGMethodDefinition

0xfff88038 M RGMethodDefinition(RGElementDefinition)>actualClass 0xc083658:
a(n) RGMethodDefinition

0xfff88050 M TestCoverage>uninstall 0xc082400: a(n) TestCoverage

0xfff88068 M TestCoverage>run:with:in: 0xc082400: a(n) TestCoverage

0xfff8808c M ByteString(String)>asSymbol 0x93007a0: a(n) ByteString

0xfff880b0 M SystemDictionary>classOrTraitNamed: 0x9895350: a(n)
SystemDictionary

0xfff880cc M SystemDictionary>classNamed: 0x9895350: a(n) SystemDictionary

0xfff880e8 M RGMethodDefinition(RGElementDefinition)>realParent 0xc083658:
a(n) RGMethodDefinition

0xfff88100 M RGMethodDefinition(RGElementDefinition)>realClass 0xc083658:
a(n) RGMethodDefinition

0xfff88118 M RGMethodDefinition(RGElementDefinition)>actualClass 0xc083658:
a(n) RGMethodDefinition

0xfff88130 M TestCoverage>uninstall 0xc082400: a(n) TestCoverage

0xfff88148 M TestCoverage>run:with:in: 0xc082400: a(n) TestCoverage

0xfff8816c M ByteString(String)>asSymbol 0x93007c0: a(n) ByteString

0xfff88190 M SystemDictionary>classOrTraitNamed: 0x9895350: a(n)
SystemDictionary

0xfff881ac M SystemDictionary>classNamed: 0x9895350: a(n) SystemDictionary

0xfff85e48 M RGMethodDefinition(RGElementDefinition)>realParent 0xc083658:
a(n) RGMethodDefinition

0xfff85e60 M RGMethodDefinition(RGElementDefinition)>realClass 0xc083658:
a(n) RGMethodDefinition

0xfff85e78 M RGMethodDefinition(RGElementDefinition)>actualClass 0xc083658:
a(n) RGMethodDefinition

0xfff85e90 M TestCoverage>uninstall 0xc082400: a(n) TestCoverage

0xfff85ea8 M TestCoverage>run:with:in: 0xc082400: a(n) TestCoverage



On Nov 26, 2017 06:00, "Ben Coman"  wrote:

The Raw Log of https://travis-ci.org/ba-st/Willow/jobs/307025742
says "The log length has exceeded the limit of 4 MB (this usually means
that the test suite is raising the same exception over and over)."

whereas the Raw Log from a working job https://travis-ci.org/ba-st/Wi
llow/jobs/303028020
is 94kB.

So you might start with some side-by-side diff tool to observe where these
log files diverge.

cheers -ben



On 26 November 2017 at 03:40, Gabriel Cotelli  wrote:

> All the latest builds I've tried are failing in Travis with "out of
> memory" errors aparently after running the tests. It's always the same
> error and for different Pharo versions (4.0 5.0 6.1 7.0 , etc)
>
> See for example https://travis-ci.org/ba-st/Willow/jobs/307025742
>
> Anyone 

Re: [Pharo-dev] Bloc Feedback

[Aliaksei Syrel]

Here is how I see the behaviour of an infinite animation:

 - stop it when element is removed from the space
 - resume it when element is re-added to the space

It means that some object should store that animation (an element?).
What if element is not going to be re-added to the space? Should animation
reference it target in a weak manner and remove itself when target is
garbage collected? However, we also have target-less animations...

There are too many possibilities, that is why I think it should be up to
the user of infinite animation how to manage its lifecycle. We could create
a factory of pre-configured infinite animations for most common lifecycles.

Cheers,
Alex

Re: [Pharo-dev] Bloc Feedback

[Aliaksei Syrel]

>
> So one would change the `loop: 1` in your example to `beInfinite`? Why
> didn't you do that in the example?


Because I wanted it to work just one minute :) I don't know, there is no
explanation for that.

 Also, what is the lifetime of an infinite animation?


It can only be stopped by sending #stop to it. It is infinite after all.
Please note, that animation target is not necessary a visual element, so we
can not stop animation when element is removed from the scene graph. It
also means that animations are not bound to any specific space, that is why
we must not stop animation when space is closed.
Infinite animations are not used yet, so we can still find some smart
heuristics for stopping.

Do you have any particular use-case for animations?

Cheers,
Alex

On 26 November 2017 at 05:23, Sean P. DeNigris <s...@clipperadams.com>
wrote:

> Aliaksei Syrel wrote
> > Stepping mechanism can be implemented using infinite animation (stepping
> > is
> > nothing else than a special case of animation).
>
> Okay, cool. So one would change the `loop: 1` in your example to
> `beInfinite`? Why didn't you do that in the example? Also, what is the
> lifetime of an infinite animation?
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>

Re: [Pharo-dev] Bloc Animations

[Aliaksei Syrel]

Hi Sean,

In Bloc it is exactly as described in the forwarded email. There is no
#step, instead everything is handled using a single unified concept of
"Animation.
Consider the following example of animated translation:

element := BlElement new
>background: (BlBackground paint: Color blue);
>size: 100 @ 100;
>relocate: 100 @ 100.
>
> (BlTransformAnimation translate: 200 @ 200)
>easing: BlEasing bounceOut;
>duration: *2 seconds*;
>startOn: element.


> element


Note, that duration is actually defined as Duration.
Example above will finish after 2 seconds regardless of how many frames
actually passed.

Cheers,
Alex

On 26 November 2017 at 00:02, Sean P. DeNigris 
wrote:

> I saw this on the Squeak ML [1] and wondered how/if this applies to Bloc…
>
>
> marcel.taeumel wrote
> > You can do a lot of stuff with plain morphs and stepping, too. In the
> > Animations framework, the focus was on a more convenient programming
> > interface that decouples system load and animation time. So, even if your
> > Squeak image has plenty of things to do, the animation X will finish
> > after, for example, 250 ms. Yet, you might only see the first and the
> last
> > update then. :D In some way, the Animations framework is kind of Morphic
> > stepping but it offers each participant a synchronized progression of
> > time, which can then be used to update or interpolate the animation
> > progress. Such things are difficult with Morphic stepping because the
> > "call me again in 20 ms" via #stepTime treats time different for each
> > morph.
>
> 1. http://forum.world.st/Fun-with-Animations-tp5029046p5030234.html
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>

Re: [Pharo-dev] [Moose-dev] How ready is Bloc for a simple use-case?

[Aliaksei Syrel]

No, mind map was not implemented :)

Cheers,
Alex

On 26 November 2017 at 00:01, Sean P. DeNigris <s...@clipperadams.com>
wrote:

> Aliaksei Syrel wrote
> > Yes, the idea of a simple game in Bloc progressed in a tutorial and a
> > booklet.
>
> Thanks. I went through the tutorial and enjoyed it. My message was
> specifically about a mind map implementation :)
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>

Re: [Pharo-dev] [Moose-dev] How ready is Bloc for a simple use-case?

[Aliaksei Syrel]

Hi Sean,

Yes, the idea of a simple game in Bloc progressed in a tutorial and a
booklet.
Here is the repo with all needed information and a link to the booklet:

https://github.com/pharo-graphics/Tutorials/

I highly recommend to do a step-by-step tutorial :)
It teaches how to create new elements, draw on canvas, compose elements and
handle ui events.

Cheers,
Alex

On 25 November 2017 at 23:31, Sean P. DeNigris <s...@clipperadams.com>
wrote:

> Aliaksei Syrel wrote
> > We could try to do it together and maybe even make a video (stream) of
> > implementation process :)
> >>  The idea for me is to make a simple mindmap
>
> Did you guys ever make any progress on this? I am very interested and would
> like to participate if it becomes a team effort…
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>

Re: [Pharo-dev] Bloc Tutorial Feedback

[Aliaksei Syrel]

Hi Sean,

That is awesome, thank you! :)

- The booklet reached from the GH readme seems out of sync with Bloc. I had
> to alter a lot of the animations from the loaded code e.g.
> BlTransformAnimation did not exist (I used BlScaleAnimation instead),
> animations didn't understand #absolute, ` animation startOn: target` needed
> to be changed to `animation target: target; start`, etc.


That is the Iceberg issue (https://github.com/pharo-vcs/iceberg/issues/479).
Tutorial requires you to load a stable version of Bloc from *pharo6.1*
branch. However, iceberg does not do that and instead loads an ancient bloc
version from #master branch because you probably have a shared repo of bloc
somewhere on your machine.
The tutorial's code is up-to date :)

Could you try to remove any bloc clones from you computer, take a fresh
pharo6.1 image and install Tutorial following the readme? (
https://github.com/pharo-graphics/Tutorials)

Cheers,
Alex

On 24 November 2017 at 08:38, Stephane Ducasse 
wrote:

> Aliaksei told me that he should do another pass to add animations and
> layout chapters.
> I imagine that he did some refactorings so this is good that you spotted
> them.
>
>
> On Fri, Nov 24, 2017 at 8:36 AM, Stephane Ducasse
>  wrote:
> > Thanks Sean I will have a look when I get some time.
> >
> >
> > On Fri, Nov 24, 2017 at 4:41 AM, Sean P. DeNigris 
> wrote:
> >> I did a native English review pass on the first half and submitted a PR
> on
> >> GH.
> >>
> >> A few other items:
> >> - When clipping is used to initially draw the card outline as a rounded
> >> rect, instead of using the rect as a path, it's not immediately obvious
> why
> >> this is done. It's only way later when the cross is drawn on the back
> of the
> >> card that one /may/ realize that it's so card contents (e.g. the cross)
> >> don't get drawn outside the rounded bounds. It would be good to explain
> this
> >> upfront.
> >> - The booklet reached from the GH readme seems out of sync with Bloc. I
> had
> >> to alter a lot of the animations from the loaded code e.g.
> >> BlTransformAnimation did not exist (I used BlScaleAnimation instead),
> >> animations didn't understand #absolute, ` animation startOn: target`
> needed
> >> to be changed to `animation target: target; start`, etc.
> >>
> >> Otherwise a very nice tutorial. Thanks!
> >>
> >>
> >>
> >>
> >> -
> >> Cheers,
> >> Sean
> >> --
> >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.ht
> ml
> >>
>
>

[Pharo-dev] nil suspend

[Aliaksei Syrel]

Hi,

I was looking at nil (already funny) and found a very interesting method:

suspend
   "Kills off processes that didn't terminate properly"
   "Display reverse; reverse."  "<-- So we can catch the suspend bug"
   Processor terminateActive

It means that the following code is probably the shortest way to kill your
image (save first!)

nil suspend

It terminates a UI process if evaluated from anywhere using CMD+d :D

Cheers,
Alex

Re: [Pharo-dev] nil inspect

[Aliaksei Syrel]

Yes

[image: Inline images 1]

Cheers,
Alex

On 18 November 2017 at 21:56, Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com> wrote:

> Anyone tried 'nil inspect' recently?
>

[Pharo-dev] Pharo6.1 World menu order

[Aliaksei Syrel]

Hi,

I find world menu order in Pharo 6.1. with enable Iceberg a little bit
awkward :)

[image: Inline images 1]

Any thought on why Iceberg is the first? It breaks muscle memory.

P.S. To fix the order remove `parent: #'MostUsedTools'`
from IceRepositoriesBrowser class>>#menuCommandOn: so that implementation
is:

menuCommandOn: aBuilder
"Add a custom menu item to the world menu"


(aBuilder item: #'Iceberg')
order: 0.8;
icon: self icon;
"parent: #'MostUsedTools';   <-- remove"
keyText: 'o, i';
action: [ self open ].



Cheers,
Alex

Re: [Pharo-dev] feenk log

[Aliaksei Syrel]

Hi Sean,

Why not `anElement simulateClick`?


Good question :)
We indeed evaluated a possibility to have (BlElement >> #simulateClick) but
then decided to make BlSpace class to be responsible for that.

First we should realise that when we simulate a click we do literally
simulate user's action which is: mouseDown at some global coordinate in
space and then mouseUp. A process of handing mouse down/up events involves
some complex event processing in order to detect what should happen, for
example, with currently focused element or if we need to send double-click
event. It is a mouse processor who is responsible for all these actions and
it belongs to Space (inst. var in space). Not to mention some weird cases
of overlapped elements, elements with custom elevation (zIndex), custom
mouseDown/up event listeners that do some work too...
That is why it is definitely not enough just to send a plain BlClickEvent
directly to the element. Instead, we should involve a space in the process
and actually simulate it by pushing mouseDown and mouseUp events to the
event queue.

Next what we realised it the fact that it is not nice to always create a
temporary space and add our element to it in order to simulate a click.
What if an element is already added to the space, what if not?
To wrap up, we decided that it should be a responsibility of the Space
*class* to create a new temporary instance of itself, add an element to it,
simulate click event and then delete itself. In order to show the intent
and a process behind we decided that it would be a good idea to actually
write a code like this:

BlSpace simulateClickOn: element.

In english it is quite nice:

"dear space class, could you, please, simulate a click event on a given
element?" *It is a space who simulates event, not an element.*

P.S. Users can still send a BlClickEvent directly (informs 'click'):

element := BlElement new.
element addEventHandlerOn: BlClickEvent do: [ self inform: 'click' ].
element fireEvent: BlClickEvent new

Cheers,
Alex

On 10 November 2017 at 21:22, Sean P. DeNigris 
wrote:

> Tudor Girba-2 wrote
> > - support for programatic testing of bloc mouse events:
> > https://twitter.com/feenkcom/status/925672206763511808
>
> Why not `anElement simulateClick`?
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>

Re: [Pharo-dev] feenk log

[Aliaksei Syrel]

Hi Stef,

In this email I will enumerate what features are missing that we are aware
of. The problem is that we discover what we need spontaneously during
experiments and not beforehand :)

Missing / broken
 - error handling library. If there is an exception during event handling
or rendering, Bloc's UI thread stops and we have to reset the universe.
Sometimes errors cause "infinite" spawn of debuggers.
 - transformations (scale, translate, rotate) animations don't work now,
because I still need to finish interpolation of matrix decomposition.
 - there is a bug with drawing invalidation when element has rotation
transformation.
 - gradient backgrounds can only have fixed size (origin/corner) and can
not scale according to element's size.
 - event propagation mechanism should be implemented on top of Announcer
and not using our custom one (there was a discussion about this on dev
mailing list)
 - Sparta/Cairo backend has not implemented fill path with image pattern
API method
 - FFI Callbacks crash VM on windows (I have my own FFI-only tests that
fail)
 - FFI external array can not handle booleans:

array := FFIExternalArray externalNewType: 'bool' size: 1. array at: 1 put:
true. array at: 1 "false"

More minor issues can be found on Bloc's github page
https://github.com/pharo-graphics/Bloc/issues

That is all from my side :)

Cheers,
Alex

On 25 October 2017 at 18:48, Aliaksei Syrel <alex.sy...@gmail.com> wrote:

> Hi Denis,
>
> The reason for BlVector2D is that we also have BlVector*3*D.
> In case of translation a Point (x@y) should be converted to (x,y,0). For
> scale it is converted as (x,y,1). You see, the same Point object has
> different meanings when it comes to different transformations.
>
> Additionally, Point does not represent the intent correctly because all
> affine transformations involve vectors. Of course, we made Vectors
> polymorphic with points, so users can write:
> element translateBy: (20@20) instead of element translateBy: (BlVector x:
> 20 y: 20).
>
> - How often this vector will be constructed by hands in user code? It is
>> related to my question about comma message: is it really needed?
>
>
> In lineare algebra vectors are represented as (x, y, z).  Beautiful!
>
> Cheers,
> Alex
>

Re: [Pharo-dev] feenk log

[Aliaksei Syrel]

Hi Denis,

The reason for BlVector2D is that we also have BlVector*3*D.
In case of translation a Point (x@y) should be converted to (x,y,0). For
scale it is converted as (x,y,1). You see, the same Point object has
different meanings when it comes to different transformations.

Additionally, Point does not represent the intent correctly because all
affine transformations involve vectors. Of course, we made Vectors
polymorphic with points, so users can write:
element translateBy: (20@20) instead of element translateBy: (BlVector x:
20 y: 20).

- How often this vector will be constructed by hands in user code? It is
> related to my question about comma message: is it really needed?


In lineare algebra vectors are represented as (x, y, z).  Beautiful!

Cheers,
Alex

Re: [Pharo-dev] Bloc Feedback

[Aliaksei Syrel]

Hi Sean,

Thanks for the feedback :)
I will take a look and come up with an answer in a few days.

If you have time to play more or if you found other issues, please feel
free to list them here or open bug reports on Github (
https://github.com/pharo-graphics/Bloc/issues)

Cheers,
Alex

On 23 October 2017 at 04:15, Sean P. DeNigris  wrote:

> Highlights:
>
> - BlCornerRadii - 1st class corners - yay to the death of cryptic arrays
> for
> this kind of thing :)
>
> Questions:
>
> - How would one do e.g. a ticking clock in Bloc? The only possibly relevant
> example I see is BlAnimatedCursor. Is that a typical usage? One thing that
> I'm not sure how to translate to a BlElement is that the cursor seems to be
> responsible for starting and stopping the animation via #activateOn:, which
> doesn't exist for an element. How would one prevent an element's animation
> from continuing to run after a space was closed?
> - BlElement has 278 instance-side methods. A frequent battle cry against
> Morphic was the bloated Morph class with 899. Definitely an improvement,
> but
> are we "there yet"?
> - Does Bloc implement its own keybinding outside of "Keymapping" e.g.
> BlShortcut? If so, why? Will it ultimately be a replacement?
> - In BlTextEditElement class>>#exampleText, text construction seems awfully
> complex (`text := BrRopedText rope: (BrCollectionRope collection: (String
> loremIpsum: 30)). text attributes: { BrFontWeightAttribute bold }.`. How
> does that way contrast to e.g. `'X' asRopedText`?
>
> Problems:
>
> BlBasicExamples
> - #exampleShapes, select the yellow shape with red border -> inspector ->
> Transformations Tab -> Click on Composition -> "ShouldNotImplement:
> #multiplyOn: should not have been implemented in BlCompositeTransformation"
> - #exampleImageBackground -> "ShouldBeImplemented: #fillPath:withForm:
> should have been implemented in SpartaCairoFillPainter"
> BlTextEditElement class>>#exampleText
> - insert some characters and then press [delete] -> "Error: Illegal
> sub-sequence end index: 44"
> - There is aBlSelectionHandler, but I can't seem to select any of the
> text
> BrAttributeRopeExamples#>>simpleRope -> inspect return value -> In
> inspector, click on "Children" tab -> "Error: Improper store into indexable
> object"
> - In BlLinearLayoutExamples class>>#exampleVerticalLeftCenterRightRTL,
> - the red sub-element does `c linear horizontal alignLeft`, which is
> then overridden by its parent's `BlLinearLayout vertical "rightToLeft"`.
> Was
> it intentional to show the precedence because I found it confusing when an
> element that sent #alignLeft showed up on the right!
> - the yellow sub-element does not appear at all. Maybe it should do a
> `c
> vertical exact: 100.` like its siblings?
> - All BlAnimationExamples lead to deprecation warnings and DNU's, but *do
> not even attempt* #exampleBallsAnim or face endlessly multplying debugger
> windows!
>
>
>
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
>
>

Re: [Pharo-dev] [Pharo-users] [ann] moldable brick editor - alpha

[Aliaksei Syrel]

Hello Stephan,


> Yep. I tried with a clean 6.1 install.
> The Moz2D library is downloaded, but does not seem to be installed
> correctly


Below is the list of dependencies for *64bit Ubuntu* and *32bit Pharo*: (on
64bit pharo it should theoretically work out of the box, except 64bit
related issues)


> sudo dpkg --add-architecture i386;
> sudo apt-get update;
> export PKG_CONFIG_PATH=/usr/lib/i386-linux-gnu/pkgconfig/;
>
> echo "Installing c++ libraries";
> sudo apt install libstdc++6:i386;
>
> echo "Installing GTK-2.0...";
> sudo apt-get install libgtk2.0-0:i386;
> echo "Installing GTK-3.0...";
> sudo apt-get install libgtk-3-0:i386;
>
> echo "Installing libGL...";
> sudo apt-get install libglu1-mesa:i386;


We have travis Build which is green:

https://github.com/syrel/Sparta/blob/master/.travis.yml
https://travis-ci.org/syrel/Sparta

On Windows users should install Visual C++ Redistributable for Visual
Studio 2015: (reduces binary size by >10mb)
https://www.microsoft.com/en-US/download/details.aspx?id=48145

On OSX works out of the box

Cheers,
Alex

On 18 August 2017 at 17:01, stephan  wrote:

> On 12-08-17 10:47, Tudor Girba wrote:
>
>> Is this still an issue?
>>
>
> Yep. I tried with a clean 6.1 install.
> The Moz2D library is downloaded, but does not seem to be installed
> correctly
>
> > Could you also try on another OS (just to make sure)?
>
> next step
>
> Stephan
>
>

Re: [Pharo-dev] Two tables that share the same data source!?

[Aliaksei Syrel]

Hello Elhamer,

Do you have an idea when it might be useful to have two lists representing
the same datasource?
We have this feature in bloc (see video in attachment) but I didn't
encounter a real-life use-case yet...

Cheers,
Alex
​
 Bloc-TwoListsOneDataSource.mov
<https://drive.google.com/file/d/0B-bMBVDOi3oTVWpYdzF5dmlIT2Ftbm9yUVBpazNMVE9HMFhr/view?usp=drive_web>
​
On 8 August 2017 at 02:16, Aliaksei Syrel <alex.sy...@gmail.com> wrote:

> Hello Elhamer,
>
> Do you have an idea when it might be useful to have two lists representing
> the same datasource?
> We have this feature in bloc (see video in attachment) but I didn't
> encounter a real-life use-case yet...
>
> Cheers,
> Alex
>
> On 8 August 2017 at 01:36, Elhamer <abdelkhalek...@gmail.com> wrote:
>
>> Hello everybody,
>>
>> How common is it for multiple tables (FastTables) to have the same
>> datasource ?
>>
>> The FTDataSource has a instance variable to refer a table:
>>
>> 
>> Object subclass: #FTDataSource
>> instanceVariableNames: 'table'
>> classVariableNames: ''
>> package: 'Morphic-Widgets-FastTable-DataSource'
>> ```
>>
>>
>> which makes it impossible for several tables to have the same data source.
>> the code of the data source is also coupled to the ft code which also
>> makes
>> it harder to extend.
>>
>> I've tried to go down the rabbit hole and decouple the data source from
>> the
>> table but things went messy. So i would like to know how common it is for
>> several tables to share the same ds, and does that worth going the extra
>> mile ?
>>
>> Thanks,
>> Elhamer.
>>
>>
>>
>> --
>> View this message in context: http://forum.world.st/Two-tabl
>> es-that-share-the-same-data-source-tp4959153.html
>> Sent from the Pharo Smalltalk Developers mailing list archive at
>> Nabble.com.
>>
>>
>

[Pharo-dev] Zinc redirect bug?

[Aliaksei Syrel]

Hello,

I am trying to download a file from *bintray* with the help of ZnClient.
I'm doing the following:

ZnClient new
   systemPolicy;
   url: '
https://dl.bintray.com/syrel/Moz2D/osx/development/i386/libMoz2D.dylib';
   get;
   yourself

which results in Error 403.

At the same time wget works as expected:

wget https://dl.bintray.com/syrel/Moz2D/osx/development/i386/libMoz2D.dylib

Trying to open this url in a browser works too.

I tried to find out what may cause the error and it looks like it is
something related to redirects because request and response headers look
good...

Thanks,
Alex

[Pharo-dev] A better way to serialise methods?

[Aliaksei Syrel]

Hi,

Smalltalk is famous for tiny methods with just a few parameters. However,
sometimes libraries written in C have methods that accept many arguments.
In my case I have a method that requires to pass exactly 15 arguments,
luckily 15 is maximum possible amount of arguments in Pharo, so my day was
saved. Until I tried to load the same code in Window. Here is my ffi call
method:

primMeasure: aTextRun start: aStart length: aMaxLength breakBefore:
aLineBreakBefore width: aWidth provider: aProvider suppress: aSuppressBreak
whitespace: aTrimWhitespace metrics: aMetrics boxType: aBoundingBoxType
canvas: aCanvas hyphen: aUsedHyphenation lastBreak: aLastBreak wordWrap:
aCanWordWrap breakPriority: aBreakPriorityPointer

^ self ffiCall: #(uint32 text_run_break_and_measure (
TextRun aTextRun,
uint32 aStart,
uint32 aMaxLength,
bool aLineBreakBefore,
double aWidth,
TextPropertyProvider aProvider,
TextSuppressBreak aSuppressBreak,
ExternalAddress aTrimWhitespace,
NativeTextMetrics aMetrics,
TextBoundingBoxType aBoundingBoxType,
Canvas aCanvas,
ExternalAddress aUsedHyphenation,
ExternalAddress aLastBreak,
bool aCanWordWrap,
ExternalAddress aBreakPriorityPointer))

If I try to commit it using filetree/gitfiletree/Iceberg I get an .st
method source file with the following name (138 characters):

>
> primMeasure.start.length.breakBefore.width.provider.suppress.whitespace.metrics.boxType.canvas.hyphen.lastBreak.wordWrap.breakPriority..st


And of course trying to clone the repo using git fails on Window because
filename is too long.
So here comes the question: *Is it really necessary to name method source
file according to the method's #sender? Would it make sense to trim the
filename and append a short hash to avoid collisions?*

Cheers,
Alex

[Pharo-dev] Sources location inconsistency between WIndows and OSX

[Aliaksei Syrel]

Hi,

I just realised that on OSX it is enough to put .sources in the same folder
with Pharo.app which is extremely cool because there is no need to carry
them around with images.

However, in case of Window it is different. I tried to put .source in the
same folder with Pharo.exe but got a notification that sources in the
*image* folder were not found.

It would be great to unify this behaviour among platforms :)
I prefer OSX .sources location strategy.

Cheers,
Alex

Re: [Pharo-dev] Working OSProcess configuration for Pharo 6 release (please)

[Aliaksei Syrel]

But now OSX latest VM (http://files.pharo.org/vm/pha
ro-spur32/mac/pharo-mac-i386-201706280928-1bd79a7.zip) crashes when trying
to load a project using Iceberg without crash.dmp. I only get the following
in terminal:

Pharo(4280,0xa6f3b1c0) malloc: *** error for object 0x8416a314: incorrect
checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug

I tested with both 60501 and 60503 images to prove that it is a VM problem,
because it works well with 60501 and Stable :)
Maybe it is somehow related to the new version of libgit in the latest vm...

Cheers,
Alex

On 28 June 2017 at 18:26, Aliaksei Syrel <alex.sy...@gmail.com> wrote:

> Hi Eliot,
>
> I confirm that OSX performance issue is fixed in latest VM (
> http://files.pharo.org/vm/pharo-spur32/mac/pharo-mac-i386-2
> 01706280928-1bd79a7.zip).
> Thanks a lot!
>
> Cheers,
> Alex
>
> On 22 June 2017 at 08:39, Clément Bera <bera.clem...@gmail.com> wrote:
>
>>
>>
>> On Thu, Jun 22, 2017 at 8:03 AM, Stephane Ducasse <
>> stepharo.s...@gmail.com> wrote:
>>
>>> Clement why you cannot load OSSubprocess?
>>>
>>>
>> 1) project has to work on itimer Linux VM.
>> 2) existing project working with OSProcess and I don't want to spend time
>> migrating.
>> 3) code base has to work at least in Squeak and Pharo, I don't want to
>> add extra code so it uses different frameworks in different platforms and
>> then maintain this extra code.
>>
>>
>>>
>>>
>>> On Tue, Jun 20, 2017 at 3:10 PM, Clément Bera <bera.clem...@gmail.com>
>>> wrote:
>>> > Hi Thierry, hi all,
>>> >
>>> > The Pharo catalog version of OSProcess is not working in the Pharo 6
>>> release
>>> > and I need to load OSProcess in one of my projects. I cannot load
>>> > OSSubProcess instead, so no need to answer this mail talking about it.
>>> >
>>> > In-between version 2231 and 2241 of VMMaker, the vm parameter 1002 (os
>>> > version), has changed on Mac from '1011.6' to '10.11.6'. OSProcess
>>> tests the
>>> > version number against 1000, and should now test against 10.
>>> >
>>> > I checked the SqueakSource repo of OSProcess, I can see that the last
>>> > version is 4.6.8 and the catalog configuration loads an older version,
>>> but I
>>> > cannot see any fix related to the version number ?
>>> >
>>> > Can someone update the OSProcess configuration in the Pharo catalog so
>>> that
>>> > it loads a working version in the Pharo 6 release or point me to an
>>> > OSProcess configuration, outside of the catalog, which works in the
>>> release
>>> > of Pharo 6 please ?
>>> >
>>> > Thank you very much.
>>> >
>>> > Clement
>>>
>>>
>>
>

Re: [Pharo-dev] Working OSProcess configuration for Pharo 6 release (please)

[Aliaksei Syrel]

Hi Eliot,

I confirm that OSX performance issue is fixed in latest VM (
http://files.pharo.org/vm/pharo-spur32/mac/pharo-mac-i386-201706280928-1bd79a7.zip
).
Thanks a lot!

Cheers,
Alex

On 22 June 2017 at 08:39, Clément Bera  wrote:

>
>
> On Thu, Jun 22, 2017 at 8:03 AM, Stephane Ducasse  > wrote:
>
>> Clement why you cannot load OSSubprocess?
>>
>>
> 1) project has to work on itimer Linux VM.
> 2) existing project working with OSProcess and I don't want to spend time
> migrating.
> 3) code base has to work at least in Squeak and Pharo, I don't want to add
> extra code so it uses different frameworks in different platforms and then
> maintain this extra code.
>
>
>>
>>
>> On Tue, Jun 20, 2017 at 3:10 PM, Clément Bera 
>> wrote:
>> > Hi Thierry, hi all,
>> >
>> > The Pharo catalog version of OSProcess is not working in the Pharo 6
>> release
>> > and I need to load OSProcess in one of my projects. I cannot load
>> > OSSubProcess instead, so no need to answer this mail talking about it.
>> >
>> > In-between version 2231 and 2241 of VMMaker, the vm parameter 1002 (os
>> > version), has changed on Mac from '1011.6' to '10.11.6'. OSProcess
>> tests the
>> > version number against 1000, and should now test against 10.
>> >
>> > I checked the SqueakSource repo of OSProcess, I can see that the last
>> > version is 4.6.8 and the catalog configuration loads an older version,
>> but I
>> > cannot see any fix related to the version number ?
>> >
>> > Can someone update the OSProcess configuration in the Pharo catalog so
>> that
>> > it loads a working version in the Pharo 6 release or point me to an
>> > OSProcess configuration, outside of the catalog, which works in the
>> release
>> > of Pharo 6 please ?
>> >
>> > Thank you very much.
>> >
>> > Clement
>>
>>
>

Re: [Pharo-dev] Working OSProcess configuration for Pharo 6 release (please)

[Aliaksei Syrel]

The problem is that stable VM crashes every 10min when I type (the same
problem as Doru has) and latest is slow.
My current crash.dmp is already 934 KB while single typing related crash
produces 8 KB of output. It means that Pharo crashed > 100 times!

:(

On 20 June 2017 at 19:26, Aliaksei Syrel <alex.sy...@gmail.com> wrote:

> Hi Eliot,
>
> I experience the same slowness as Cyril.
> Latest Pharo's UI is completely unresponsive and it takes seconds to open
> new windows, resizing is a nightmare.
>
> I made two videos comparing latest and stable VMs. I used 32bit
> Pharo-60501 on OSX Sierra 10.12.5.
> ​
>  Pharo-VMLatest.mov
> <https://drive.google.com/file/d/0B-bMBVDOi3oTXy1wNmlSTlV5THM/view?usp=drive_web>
> ​​
>  Pharo-VMStable.mov
> <https://drive.google.com/file/d/0B-bMBVDOi3oTX3AzUkNqcng3dUk/view?usp=drive_web>
> ​
> Cheers,
> Alex
>
> On 20 June 2017 at 19:14, Eliot Miranda <eliot.mira...@gmail.com> wrote:
>
>> Hi Cyril,
>>
>> On Tue, Jun 20, 2017 at 8:08 AM, Cyril Ferlicot <cyril.ferli...@gmail.com
>> > wrote:
>>
>>> On Tue, Jun 20, 2017 at 5:04 PM, Eliot Miranda <eliot.mira...@gmail.com>
>>> wrote:
>>> > Hi Clément
>>> >
>>> >
>>> > That was a mistake of mine.  In the current VM it now answers e.g.
>>> 1011.6 and so things should be working again.
>>> >
>>>
>>> Hi!
>>>
>>> The problem is that the stable vm does not have the fix and the
>>> current latest vm is **rally* slow. It happens at least on
>>> OSX.
>>
>>
>> Can you say more?  I'm noticing slow start up on the latest VMs but once
>> it is running I see no issue.  What specifically is running slowly for you?
>>
>>
>>> I don't know if it is a known problem or if it comes from the
>>> opensmalltalk build or the pharo build.
>>>
>>> I got the VM here: http://files.pharo.org/vm/pharo-spur32/mac/
>>>
>>>
>>>
>>> --
>>> Cyril Ferlicot
>>> https://ferlicot.fr
>>>
>>> http://www.synectique.eu
>>> 2 rue Jacques Prévert 01,
>>> 59650 Villeneuve d'ascq France
>>>
>>>
>>
>>
>> --
>> _,,,^..^,,,_
>> best, Eliot
>>
>
>


pharo-crash.dmp
Description: Binary data

Re: [Pharo-dev] Working OSProcess configuration for Pharo 6 release (please)

[Aliaksei Syrel]

Hi Eliot,

I experience the same slowness as Cyril.
Latest Pharo's UI is completely unresponsive and it takes seconds to open
new windows, resizing is a nightmare.

I made two videos comparing latest and stable VMs. I used 32bit Pharo-60501
on OSX Sierra 10.12.5.
​
 Pharo-VMLatest.mov

​​
 Pharo-VMStable.mov

​
Cheers,
Alex

On 20 June 2017 at 19:14, Eliot Miranda  wrote:

> Hi Cyril,
>
> On Tue, Jun 20, 2017 at 8:08 AM, Cyril Ferlicot 
> wrote:
>
>> On Tue, Jun 20, 2017 at 5:04 PM, Eliot Miranda 
>> wrote:
>> > Hi Clément
>> >
>> >
>> > That was a mistake of mine.  In the current VM it now answers e.g.
>> 1011.6 and so things should be working again.
>> >
>>
>> Hi!
>>
>> The problem is that the stable vm does not have the fix and the
>> current latest vm is **rally* slow. It happens at least on
>> OSX.
>
>
> Can you say more?  I'm noticing slow start up on the latest VMs but once
> it is running I see no issue.  What specifically is running slowly for you?
>
>
>> I don't know if it is a known problem or if it comes from the
>> opensmalltalk build or the pharo build.
>>
>> I got the VM here: http://files.pharo.org/vm/pharo-spur32/mac/
>>
>>
>>
>> --
>> Cyril Ferlicot
>> https://ferlicot.fr
>>
>> http://www.synectique.eu
>> 2 rue Jacques Prévert 01,
>> 59650 Villeneuve d'ascq France
>>
>>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>

Re: [Pharo-dev] [ bloc]'Pulse loop must be running in order to request a pulse'

[Aliaksei Syrel]

https://github.com/pharo-graphics/Bloc/issues/20

Cheers,
Alex

On 20 May 2017 at 14:58, Aliaksei Syrel <alex.sy...@gmail.com> wrote:

> Hi Stef,
>
> Yes, sometimes that might happen.
> However, there is silver bullet:
>
> BlUniverse reset
>
> Cheers,
> Alex
>
> On May 20, 2017 2:09 PM, "Stephane Ducasse" <stepharo.s...@gmail.com>
> wrote:
>
> I wanted to work on the bloc booklet and
> when I reopen my image I get
>
> 'Pulse loop must be running in order to request a pulse'
>
>
>

Re: [Pharo-dev] [ bloc]'Pulse loop must be running in order to request a pulse'

[Aliaksei Syrel]

Hi Stef,

Yes, sometimes that might happen.
However, there is silver bullet:

BlUniverse reset

Cheers,
Alex

On May 20, 2017 2:09 PM, "Stephane Ducasse"  wrote:

I wanted to work on the bloc booklet and
when I reopen my image I get

'Pulse loop must be running in order to request a pulse'

Re: [Pharo-dev] [Moose-dev] Re: [ann] bloc & cairo+morphic

[Aliaksei Syrel]

Hi Torsten,

There might be a random problem with "proxy" server. The initial problem is
that I could not find a way how to download a file from bintray.com using
Pharo built-in download services. That is why I had to create a "proxy"
server based on my private page as a temporary workaround.

I tried it now with the image 60483 and it worked... Please, try again,
maybe it will work.

P.S. Sometimes our CI builds fails because of Moz2D download, which hangs
and then throws timeout error. Well, at least we have #core that works 100%
regardless of anything :D

Cheers,
Alex

On 10 May 2017 at 13:15, Torsten Bergmann  wrote:

> When I try to download on OSX the #dev version as outlined on Tudors blog
> the download of the Moz2D lib for OSX fails: code tries to #download in
> class MozLibraryMacInstaller from
>
> http://syrel.ch/download.php?url=https://dl.bintray.com/
> syrel/Moz2D/osx/development/i386/libMoz2D.dylib
>
> which just hangs as it is not receiving a response.
>
> Any comments?
>
> Thx
> T.
>
>
> > Gesendet: Dienstag, 09. Mai 2017 um 14:04 Uhr
> > Von: "Alexandre Bergel" 
> > An: "Pharo Development List" 
> > Cc: "Moose-related development" , "Any
> question about pharo is welcome" 
> > Betreff: Re: [Pharo-dev] [ann] bloc & cairo+morphic
> >
> > This is amazing! I gave a try an it really looks great!
> >
> > Alexandre
> >
> >
> > > On May 8, 2017, at 6:00 PM, Tudor Girba  wrote:
> > >
> > > Hi,
> > >
> > > We are happy to announce that based on the work of Glenn, Alex
> extended Bloc (Sparta) to work directly in the Morphic world using Cairo as
> a backend.
> > >
> > > Cairo is less powerful than Moz2D (see the screenshot below for an
> example), but the implementation addresses a concern that the community
> raised regarding a perceived increased liability due to the dependency to
> Moz2D. Essentially this means that Bloc can be treated as another graphical
> library that can coexist with Morphic without requiring any external VM
> plugin.
> > >
> > > 
> > >
> > > I would also like to point out that adding a new backend and host was
> possible because of the many iterations (including throwing away whole
> implementations) that Alex and Glenn went through. I think they did an
> amazing job.
> > >
> > > You can find a bit more details about Bloc here:
> > > http://www.humane-assessment.com/blog/bloc-flexible-backends-hosts/
> > >
> > > Another issue raised regarding Bloc was that of the engineering effort
> required to make it a reality. That is why I would also like to announce
> that Alex joined feenk.com where he is primarily working on the graphical
> stack for Pharo.
> > >
> > > Cheers,
> > > Doru
> > >
> > >
> > > --
> > > www.tudorgirba.com
> > > www.feenk.com
> > >
> > > "To lead is not to demand things, it is to make them happen."
> > >
> > >
> > >
> > >
> >
> >
> >
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev
>

[Pharo-dev] Adding class side inst.var to a class using Trait results in nil message sent

[Aliaksei Syrel]

Hi,

Screenshot tells everything :)
I was trying to add "asdasd" inst var

[image: Inline images 1]

Cheers,
Alex

[Pharo-dev] (Iceberg?) Merge compiles copies of trait methods in user classes

[Aliaksei Syrel]

Hi,

Time to time I notice that suddenly Trait methods are copied to user
classes. And now I realised that this happens as the result of merge even
if there are no differences in that particular Trait. Sometimes I manage to
notice new methods in changes window but sometimes not, and then after
months it is extremely difficult to find bugs related to copied methods,
because I may change Trait code expecting that it will be updated in all
users of that trait...

Unfortunately I don't have a testcase that reproduces this issue.. sorry..
Just wanted to let you know, maybe it is something that can be fixed before
release...

Cheers,
Alex

Re: [Pharo-dev] Esteban’s list of blocking issues for release Pharo 6.0 (updated to April 10)

[Aliaksei Syrel]

Hi Esteban,

Is there a chance to have a fully working SDL2? (remember that conflicting
issue with main window)
I am just curious :)

Cheers,
Alex

On 10 April 2017 at 09:20, Esteban Lorenzano  wrote:

> Hello,
>
> This are the pending issues for release Pharo 6.0:
>
> VM:
> ===
> - NEW: there is a problem with latest VM and primitiveFindSubstring that
> needs to be fixed.
> - make all tests pass (there are still some failing tests when compiling a
> new VM).
> - libgit2: Still not there, Jan and Ben were trying and sent some
> suggestions but I still didn’t had the time to test it.
>
> Image:
> =
> - iceberg hit the image
>
> Fixed last week:
> -
>
> - win32, cairo fonts problem
> - leak revision by Pavel
> (and of course several issues not mentioned in the list).
>
> Next:
> - Make the release!
> - Test the new process and tape some videos explaining how we will
> contribute with a bootstrapped process using github :)
>
> By the way… this is a list we have to accomplish in order to make a
> release (so you know our pain):
>
> - Prepare release notes
> Image:
> - add welcome browser
> - generate PharoV60.sources
> - move SystemVersion
> - prepare new ScriptLoader70 package (in theory, this will not needed
> anymore but better to have it as a backup :P)
> VM:
> - stable for 6.0 release
> WebSite:
> - Update index
> - Update download page
> Infrastructure:
> - ZeroConf: Open new 7.0 development
> - SmalltalkCI: Open new 7.0 development
> - Create platform stable versions
> - Jenkins: move all CI projects to Pharo 7.0 (again some will not needed
> anymore, notable those moved to travis, but still)
> - And talking about travis: prepare all new process on
> github/travis/appveyor
> Pub:
> - announce post
> - announce mail
> - post to YC, Reddit
>
> … and I’m sure I’m forgetting a lot more I will remember in the process of
> making the release.
>
> (which is one of the reasons why we do not have “more releases in a year”)
>
> Anyway, do not despair… we are almost there!
>
> cheers!
> Esteban
>
>
>
>

Re: [Pharo-dev] More Windows VM Crashing -_-

[Aliaksei Syrel]

Hi all,

I got a strange crash on Mac, never saw any similar crash dump.

Image: 6.0 #60447

5.0  Mac OS X built on Mar 10 2017 13:46:32 UTC Compiler: 4.2.1 Compatible
> Apple LLVM 7.3.0 (clang-703.0.31) [Production Spur VM]
> CoInterpreter * VMMaker.oscog-eem.2146 uuid: 
> da6aee6e-4738-4161-b221-3c8135ac1bf7
> Mar 10 2017
> StackToRegisterMappingCogit * VMMaker.oscog-eem.2146 uuid:
> da6aee6e-4738-4161-b221-3c8135ac1bf7 Mar 10 2017
> VM: 201703101242 https://github.com/pharo-project/pharo-vm.git $ Date:
> Fri Mar 10 13:42:34 2017 +0100 $
> Plugins: 201703101242 https://github.com/pharo-project/pharo-vm.git $



First few lines of crash (the whole dump is in attachment):

C stack backtrace & registers:
eax 0x849671d0 ebx 0x7c6e3820 ecx 0x90301065 edx 0xe000
edi 0x7c6e3820 esi 0x7c6e3820 ebp 0xbff40708 esp 0xbff404c8
eip 0x9ef29013
0   libobjc.A.dylib 0x9ef29013 objc_msgSend + 19
1   Pharo   0x0010227a reportStackState + 706
2   Pharo   0x001025d2 sigsegv + 113
3   libsystem_platform.dylib0x9f98bebb _sigtramp + 43
4   ??? 0x 0x0 + 4294967295
5   CoreFoundation  0x94671888 _CFAutoreleasePoolPop +
24
6   HIToolbox   0x9401fa35
IMKInputSessionProcessEventRefWithCompletionHandler + 125
7   HIToolbox   0x9401ebd2
InputMethodInstanceProcessEventRef_WithCompletionHandler + 135
8   HIToolbox   0x94006c9c __TSMEventToInputMethod_
WithCompletionHandler_block_invoke + 121
9   HIToolbox   0x9400b3fa __TrySendLockEvent_
BeforeEventToInputMethod_WithContinuationHandler_block_invoke + 27
10  HIToolbox   0x9400b496
__SendTSMDocumentLockEvent_WithCompletionHandler_block_invoke + 90
11  HIToolbox   0x93ddc6a3 __SendTSMEvent_
WithCompletionHandler_block_invoke + 66
12  HIToolbox   0x93ddf651 __
SendEventToEventTargetWithCompletionHandler_block_invoke + 22


Cheers,
Alex

On 22 March 2017 at 21:26, Esteban Lorenzano  wrote:

> Hi,
>
> I do not think this is a windows problem.
> At least, I had some crashes when performing compaction last days too…
> this is a crash I collected 10 mins ago, in a mac.
>
> cheers,
> Esteban
>
>
>
>
> > On 22 Mar 2017, at 10:31, Peter Uhnak  wrote:
> >
> > Hi,
> >
> > Originally I thought my VM is crashing because of FT, so I applied some
> fix from FogBugz (that is now part of Pharo 6), but that didn't help.
> >
> > So I disabled FT in settings and changed fonts to non-FT ones; didn't
> help.
> > So I completely removed FT2Plugin.dll (now settings just states that FT
> fonts are not available), but that didn't help either.
> >
> > And obviously there is no crash.dmp whatsoever (this is latest Windows
> VM).
> >
> > This crash is extremely frustrating because the crash happens _during
> saving_, which means I am losing code all the time and have to constantly
> recover them, which really makes my blood boil.
> >
> > Without crash dump I don't even know where and how to start
> investigating. Windows kindly opens Visual Studio when Pharo crashes, but
> all it shows to me is assembly, which is not very useful to me. I can
> somewhat orient myself in the C code of the VM (as I've alredy fixed some
> other issues in the VM), but here I am lost.
> >
> > 
> > 00407D7F  ret
> > 00407D80  mov eax,dword ptr ds:[00596E44h]
> > 00407D85  testal,3
> > 00407D87  jne 00407DB2
> > 00407D89  mov ecx,dword ptr ds:[596E08h]
> > 00407D8F  lea edx,[ecx-1]
> > 00407D92  cmp eax,edx
> > 00407D94  jb  00407DB2
> > 00407D96  cmp dword ptr ds:[596E10h],eax
> > 00407D9C  jb  00407DB2
> > 00407D9E  mov ecx,dword ptr ds:[5B89D0h]
> > 00407DA4  cmp dword ptr [eax-4],ecx
> > 00407DA7  jb  00407DB2
> > 00407DA9  mov eax,dword ptr ds:[00596E28h]
> > ---> 00407DAE  movzx   eax,byte ptr [eax]
> > 00407DB1  ret
> >
> > eax = 
> > ecx = 0470
> > 
> >
> > So my question I guess is:
> > How can we fix this? How can I help fix this? Because I've lost
> countless days of time and energy on this f***ing problem...
> >
> > Peter
> >
>
>
>


crash.dmp
Description: Binary data

Re: [Pharo-dev] ExternalForm was removed 10 days ago in 60413

[Aliaksei Syrel]

Aha, ok :)
Will copy, thanks!

Cheers,
Alex

On 9 March 2017 at 13:25, Pavel Krivanek <pavel.kriva...@gmail.com> wrote:

> It's own please, because it is a subclass of Form and in UnifiedFFI it
> would make a dependency of FFI on graphics
>
> -- Pavel
>
> 2017-03-09 12:15 GMT+01:00 Esteban Lorenzano <esteba...@gmail.com>:
>
>> well… it was removed and I put it on OSWindows-SDL2 because it was the
>> only place where it was being used.
>> We can move it again to a more general place (Like UnifiedFFI… or it’s
>> own).
>>
>> Esteban
>>
>> > On 9 Mar 2017, at 11:54, Aliaksei Syrel <alex.sy...@gmail.com> wrote:
>> >
>> > ... and was moved to OSWindow-SDL2 as OSSDL2ExternalForm.
>> >
>> > If we require external form but don't want to depend on OSWindow what
>> is the right way to go? Do we need to copy OSSDL2ExternalForm with project
>> specific name?
>> >
>> > Advice with best practice would be nice :)
>> >
>> > Cheers,
>> > Alex
>>
>>
>>
>

[Pharo-dev] Callback regression in Pharo 6 (60437)

[Aliaksei Syrel]

Callback instantiation:

createCallback
>^ FFICallback
>   signature: #(long (long))
>   block: [ :value | value ]


C functions:

long test(long(*function)(long), long value) {
>return function(value);

}


#include 
>
> long long_min() {
>return LONG_MIN;
> }


FFI calls:

primCall: aCallback long: aNumber
>^ self ffiCall: #(long test(FFICallback aCallback, long aNumber))



> primLongMin
>^ self ffiCall: #(long long_min())


Test case:

test
>   self
> assert: (self primCall: self createCallback long: self primLongMin)

equals: self primLongMin


self primLongMin returns -2147483648 (= LONG_MIN).
Result of callback is 0 => test fails.

P.S. works in Pharo 5

Cheers,
Alex

[Pharo-dev] ExternalForm was removed 10 days ago in 60413

[Aliaksei Syrel]

... and was moved to OSWindow-SDL2 as OSSDL2ExternalForm.

If we require external form but don't want to depend on OSWindow what is
the right way to go? Do we need to copy OSSDL2ExternalForm with project
specific name?

Advice with best practice would be nice :)

Cheers,
Alex

Re: [Pharo-dev] Frozen is melted (can you guys please be patient?)

[Aliaksei Syrel]

Hi,

In order to make Sublimish theme possible there are some important changes
to gt morphic brick themer, spotter and probably other gt tools. Hardcoded
color and style values were already considered as a serious issue and a bug.

Imho, we should integrate at least fixes on GT side :)

Thanks, Phil! Great job :)
Alex

On Mar 6, 2017 07:46, "Esteban Lorenzano"  wrote:

>
> On 6 Mar 2017, at 07:17, Esteban Lorenzano  wrote:
>
> Hi,
>
> First, let me be clear: I *like* sublimish theme (not for my use, but I
> like it), and I like (a lot) the windows list on spotter, and I like in
> general all this new additions.
>
>
> By the way, even if I like it, I would not have integrated SublimishTheme.
> For same reason I didn’t integrated DarkMetalTheme: My idea is to have just
> two themes *in image*: one white, one dark, and allow people to install
> other themes from catalog.
>
> Why? Because each class inside image becomes our responsibility and then a
> maintainability issue. With themes in particular already happened that
> existing themes became abandonware inside the image and we needed to clean
> up, not without problems.
>
> cheers,
> Esteban
>
> ps: which means also yes: that issue got integrated because I failed to
> control the flow of issues...
>
>
> And I know, most of those additions are usability enhancements so a good
> thing.
>
> But can you guys stop pushing new features into a (in theory) frozen
> version?
>
> Pharo 7 will arrive soon… *if* we can fix all things missing. If I can
> suggest an orientation, it would be good, for those that use linux and mac
> (windows is not ready), to test and help fix 64bits version.
>
> There are still plenty of bugs to fix there, like for example why Spotter
> does not shows search line.
>
> Last week I added support to Athens and SDL2 in 64bits but that meant:
>
> - some important changes in UFFI
> - discover something that seems is failing on callbacks for Cairo (no idea
> if it is a callbacks problem or an image problem that causes a callback
> problem).
>
> I would say all this and the fact we are working on 64bits in general
> deserves a lot of testing.
>
> I will add links in Pharo page to download 64bits (I’m at the train now),
> but in the mean time you can download all from here:
>
> http://files.pharo.org/get-files/60/pharo-64.zip
> http://files.pharo.org/get-files/60/pharo64-linux-latest.zip (linux)
> http://files.pharo.org/get-files/60/pharo64-mac-latest.zip (mac)
> http://files.pharo.org/get-files/60/sources.zip (in case you need them)
>
> cheers,
> Esteban
>
>
>

Re: [Pharo-dev] [Moose-dev] How ready is Bloc for a simple use-case?

[Aliaksei Syrel]

We could try to do it together and maybe even make a video (stream) of
implementation process :)

Cheers,
Alex

On 22 February 2017 at 22:02, Aliaksei Syrel <alex.sy...@gmail.com> wrote:

> Hi Peter
>
>  I wanted to ask about Bloc:
>
> Thanks for your interest :)
>
> 1) how stable is the API? e.g. if some overhaul changes to unify/whatever
>> are planned
>
>
> Api itself is in "final" state, however naming might be improved (changed
> with or without depreciations). But don't worry user-side api is already in
> a very good shape, at least from our perspective :)
>
> 2) I saw in the techtalk that you can align elements (to center, bottom,
>> ...), however is that possible with lines? Lines have to rotate, morph
>> shape, etc.
>
> 3) Are non-straight lines possible? (e.g. bezier, arc)
>
>
> Exactly :) Lines are just bloc elements as anything else: buttons, text
> images. They can be linear, can be arcs or bezier curves (both quadratic or
> cubic). Default canvas used for rendering in Bloc (SpartaCanvas) has very
> good support of vector shapes and lines.
>
>  The idea for me is to make a simple mindmap
>> - elements with some text, icons, math symbols inside
>> - connectors (non-straight lines) between elements
>
>
> It is very doable. Please, don't forget that Bloc is a low level framework
> that does not contain any widgets (existing ones will be deleted,
> especially BlLine, BlText and BlTextElement). The only responsibility Bloc
> has is to provide a basic infrastructure that does not put any constraints
> on users. Which means that if you want to have a bezier line you have to
> subclass BlElement, implement corresponding accessors for anchor points and
> override drawPathOnSpartaCanvas: in order to display you line. You can
> learn more about canvas by checking SpartaCanvas class comment and method
> comments in 'api' protocol.
>
> Layouts, alignment, transformations are part of bloc and are available to
> all subclasses of BlElement.
>
> Cheers,
> Alex
>
> On 22 February 2017 at 21:32, Peter Uhnak <i.uh...@gmail.com> wrote:
>
>>  Hi,
>>
>>  I wanted to ask about Bloc:
>>
>>  1) how stable is the API? e.g. if some overhaul changes to
>> unify/whatever are planned
>>  2) I saw in the techtalk that you can align elements (to center, bottom,
>> ...), however is that possible with lines? Lines have to rotate, morph
>> shape, etc.
>>  3) Are non-straight lines possible? (e.g. bezier, arc)
>>
>>  The idea for me is to make a simple mindmap
>> - elements with some text, icons, math symbols inside
>> - connectors (non-straight lines) between elements
>>
>>  To me (apart from the lines) it seems like it should be already doable.
>>
>>  Also either my (Morphic) Pharo is really slow, or Bloc (in the video) is
>> superfast (everything is happening instantly).
>>
>>  Thanks,
>>  Peter
>> ___
>> Moose-dev mailing list
>> moose-...@list.inf.unibe.ch
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>
>
>

Re: [Pharo-dev] [Moose-dev] How ready is Bloc for a simple use-case?

[Aliaksei Syrel]

Hi Peter

 I wanted to ask about Bloc:

Thanks for your interest :)

1) how stable is the API? e.g. if some overhaul changes to unify/whatever
> are planned


Api itself is in "final" state, however naming might be improved (changed
with or without depreciations). But don't worry user-side api is already in
a very good shape, at least from our perspective :)

2) I saw in the techtalk that you can align elements (to center, bottom,
> ...), however is that possible with lines? Lines have to rotate, morph
> shape, etc.

3) Are non-straight lines possible? (e.g. bezier, arc)


Exactly :) Lines are just bloc elements as anything else: buttons, text
images. They can be linear, can be arcs or bezier curves (both quadratic or
cubic). Default canvas used for rendering in Bloc (SpartaCanvas) has very
good support of vector shapes and lines.

 The idea for me is to make a simple mindmap
> - elements with some text, icons, math symbols inside
> - connectors (non-straight lines) between elements


It is very doable. Please, don't forget that Bloc is a low level framework
that does not contain any widgets (existing ones will be deleted,
especially BlLine, BlText and BlTextElement). The only responsibility Bloc
has is to provide a basic infrastructure that does not put any constraints
on users. Which means that if you want to have a bezier line you have to
subclass BlElement, implement corresponding accessors for anchor points and
override drawPathOnSpartaCanvas: in order to display you line. You can
learn more about canvas by checking SpartaCanvas class comment and method
comments in 'api' protocol.

Layouts, alignment, transformations are part of bloc and are available to
all subclasses of BlElement.

Cheers,
Alex

On 22 February 2017 at 21:32, Peter Uhnak  wrote:

>  Hi,
>
>  I wanted to ask about Bloc:
>
>  1) how stable is the API? e.g. if some overhaul changes to unify/whatever
> are planned
>  2) I saw in the techtalk that you can align elements (to center, bottom,
> ...), however is that possible with lines? Lines have to rotate, morph
> shape, etc.
>  3) Are non-straight lines possible? (e.g. bezier, arc)
>
>  The idea for me is to make a simple mindmap
> - elements with some text, icons, math symbols inside
> - connectors (non-straight lines) between elements
>
>  To me (apart from the lines) it seems like it should be already doable.
>
>  Also either my (Morphic) Pharo is really slow, or Bloc (in the video) is
> superfast (everything is happening instantly).
>
>  Thanks,
>  Peter
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev
>

Re: [Pharo-dev] magic numbers in gtInspectorVariableValuePairs

[Aliaksei Syrel]

They could be extracted to class vars for example TWENTY_ONE := 21. Later
if performance is still not good enough they may be changed for example to
TWENTY_ONE := 15.
(joke)

Cheers,
Alex

On 3 February 2017 at 17:08, Tudor Girba  wrote:

> There is very little meaning behind the number.
>
> The previous inspector showed the first 100 and the last 10 elements. 100
> is anyway too large for a quick inspection, so we picked another number. I
> wanted 42 but that was still large, so we are now at 21.
>
> Doru
>
>
> > On Feb 3, 2017, at 4:20 PM, Andrei Chis 
> wrote:
> >
> > Yes these numbers should be refactored
> > For collections only the first and the last 21 elements are displayed in
> the Raw view. Don't remember why 21.
> >
> > Cheers,
> > Andrei
> >
> > On Fri, Feb 3, 2017 at 3:13 AM, Ben Coman  wrote:
> > Just curious what the magic numbers here relate to...
> > and can they be factored out to a meaningful method name?
> >
> > Context>>gtInspectorVariableValuePairs
> >   "This is a helper method that returns a collection of
> >   variable_name -> value
> >   for the current object.
> >   Subclasses can override it to specialize what appears in the
> variables presentation"
> >   | bindings |
> >   bindings := OrderedCollection new.
> >
> >   1 to: (self basicSize min: 21) do: [ :index |
> >   bindings add: (index "asString""asTwoCharacterString" ->
> (self basicAt: index)) ].
> >
> >   ((self basicSize - 20) max: 22) to: (self basicSize) do: [ :index
> | "self haltIf: [ index = 99 ]."
> >   bindings add: (index "asString" -> (self basicAt: index))
> ].
> >
> >   bindings
> >   addAll: ((self class allSlots
> >   collect: [ :slot | slot name ->
> (slot read: self) ]) sort asOrderedCollection).
> >   ^ bindings
> >
> >
> > cheers -ben
> >
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Beauty is where we see it."
>
>
>
>
>
>

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Aliaksei Syrel]

Hi

I am very thankful to all participants in the discussion!

Moz2D is not integrated in Pharo, it is an optional third party library
that helped us to model and provide architectural support of a variety of
features that were not possible with Morphic and are not possible with
Cairo (or not so easy to do). It does not mean that we hate Morphic or
dislike Cairo, it is just different :)

I read all emails very carefully and clearly understand your fears. "What
if he leaves?" "Do we want Esteban to maintain yet another VM related
stuff? (because when something breaks he is almost the only one who can
help, thanks!)" "Why is it 20Mb?!"

The point is to find balance of pros and cons. Exactly as you wrote: more
features => higher complexity => increase in costs => where to find
fundings.

I absolutely agree with the idea of having a "core" cheap backend that is
easy to maintain and costs almost nothing.

We are looking into a backend for Sparta based on Cairo.
Bindings will be based on the latest stable cairo-1.14.8 (
https://www.cairographics.org/news/cairo-1.14.8), we will also add support
of different surfaces including accelerated ones in order to be ready for
compiled cairo with enabled acceleration.

Cheers,
Alex

On 27 January 2017 at 12:36, Tudor Girba <tu...@tudorgirba.com> wrote:

> Hi,
>
> > On Jan 27, 2017, at 12:20 PM, Esteban Lorenzano <esteba...@gmail.com>
> wrote:
> >
> > (I was going to answer a big mail but my observations/concerns are
> mostly targeted by Norbert and Stef)
> >
> >> On 27 Jan 2017, at 10:49, Tudor Girba <tu...@tudorgirba.com> wrote:
> >>
> >> Hi,
> >>
> >> Thanks for the detailed analysis.
> >>
> >> In summary, Cairo+Pango+SDL2 provide enough support to get a subset of
> Sparta working that would be equivalent with the Athens that we already
> have. In other words, with such a backend, when we would tell Sparta to use
> a blur effect, it will simply do nothing and the image environment can
> continue to work as it does now.
> >>
> >> I hope that everyone agrees that this is a reasonable fallback scenario
> that we can count on. And I think this is in line with what Stef was saying
> as well.
> >>
> >> With this in mind, we should also remember that the Moz2D backend works
> now which means that we can now focus on Brick to close the loop and
> provide a complete stack that more people can start utilizing, and we can
> come back to the alternative backend later.
> >>
> >> Does this path to action address the worry related to the future of
> Sparta backends?
> >
> > thanks Doru…. I think having a base system that works in all scenarios
> (even if we miss some features) and is easy to maintain is important.
>
> Ok, so this means that worry is addressed with this strategy.
>
>
> > Then you can have a different backend for complex stuff (is more or less
> the same about Ronie’s Wooden… I love to have the possibility of doing the
> things Ronie do with that, but I would never target to build my UI system
> on top of it).
>
> Of course, choosing a technology depends on the value that you want to
> create with it.
>
>
> > Even with this simplification, I would like to know why you choose to
> strip a library from a project instead testing, for example Skia (I know,
> Skia api is not stable, and is C++ and C bindings are still unstable), but
> well… others maybe.
>
> As I mentioned before, the stripping is only done for the text support
> part, not for the vector graphics support that Skia also supports. The
> Skia-equivalent part from Moz2D is compilable as is.
>
>
> > And some precisions:
> >
> > - SDL2 do allow transparent windows and windows without decorations.
> https://wiki.libsdl.org/SDL_SetWindowOpacity,
> https://wiki.libsdl.org/SDL_CreateWindow (and the flags section)
> > - Cairo do allow acceleration, we need to compile it with right backend.
> >   - I disagree is a dead technology. Instead, is a very mature
> technology… that’s why forum is not too active (even if as far as I see, it
> was never too active). Yes, maybe is not in the hype, but is cool and allow
> us to do very nice things.
> > - examples on images are slow because of how they are programmed, not
> because of cairo :)
>
> Great points. It looks like we already have the right knowledge in-house
> :).
>
>
> > cheers!
> > Esteban
> >
> > ps: instead “not doing anything” non-suported-operations could throw a
> notification (a silent one)?
>
> Sure.
>
> Doru
>
>
>
> >>
> >> Cheers,
> >> Doru
> >>
> >>
> >&

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Aliaksei Syrel]

Hi

*According to conclusion above, we will plan how to migrate to Cairo.*
We will need help with Pango.

Cheers,
Alex

On 26 January 2017 at 23:45, Aliaksei Syrel <alex.sy...@gmail.com> wrote:

> Hi
>
> (My previous email was not a joke, I don't try to troll anyone. Let tolls
> do their job in other places)
> *Let's forget Moz2D for a moment :) Imagine that it does not exist. *It
> was done just for fun and is even not in pharo repo. (
> https://github.com/syrel/Moz2D). We needed something that works and it
> was made investing just a few months of time of a single anonymous student
> during summer exams session and vacations.
>
> I would like to start maybe one of the most important discussion that will
> influence Pharo and will dictate how system will look like in a few years.
> I invite everyone to join this discussion, especially board and consortium
> members. Because here is where business starts.
>
> There are some real questions:
>
>1. Do we need Bloc or Morphic2 or %name your favourite framework%?
>2. How advanced and modern do you want it to be?
>3. What technology stack do we want to use for our new graphical
>framework?
>4. What platforms and operating systems do we want to support?
>5. How flexible technology stack should be? (some parts may change in
>the future)
>6. Who will pay for it?
>7. How many engineers can community afford?
>8. Do you know how much other systems invest in graphical frameworks?
>9. It is not a science project, isn't it?
>
> Let me first put my two cents in.
>
> Low-level UI framework (without widgets) consists of multiple parts:
>
>1. Vector graphics library to render shapes (fill, stroke, path
>builder, composition and blending operators)
>2. Font service library (to support different font formats and collect
>information about local fonts installed in the system)
>3. Text layout engine (this is where glyph positioning magic happens,
>link above too)
>4. Text shaping engine (for high quality text rendering, to understand
>the problem => http://behdad.org/text/)
>5. Complex script library (to support ligatures, split glyphs and
>other UTF8 stuff, remember https://github.com/mi
>nimaxir/big-list-of-naughty-strings
><https://github.com/minimaxir/big-list-of-naughty-strings>)
>6. Image processing library (for various image effects, like gaussian
>blur, morphology filter, gamma, displacement map, just to name a few)
>7. Hardware acceleration. Software rendering is nice, however, modern
>UIs are full of fancy stuff that require hardware acceleration.
>8. Window and Event management library. With support of borderless and
>semi-transparent windows + good support of touchpad.
>9. Custom written "Glue" library that allows all components to work
>together. Since modern libs are implemented in C++ we would need to
>implement C wrapper and a lot of integration tests.
>10. Make the whole beast cross platform.
>
>
> Did I miss something?
>
> Here are some modern technologies commonly used for mentioned parts:
>
>1. Skia, Direct2D, CoreGraphics, Cairo
>2. Fontconfig, Freetype2
>3. HarfBuzz
>4. Pango, OpenType
>5. Graphite2, FriBidi
>6. Imagemagic, SVG filters libraries
>7. Vulkan, OpenGL
>8. wxWidgets, QT, GTK, SDL2
>9. todo
>10. todo
>
> Luckily Pango covers bullets 2 - 5. It indeed sounds like a great idea!
>
> Let's assume that we stop on Cairo + Pango. According to pango.com
>
> The integration of Pango with Cairo (http://cairographics.org/) provides
>> a complete solution with high quality text handling and graphics rendering.
>
>
> According to the this potential technology stack we will have:
>
>- Cairo for vector graphics and rendering of basic shapes
>- Pango for text rendering
>- SDL2 for window and events management
>
> What we will not get:
>
>- Support of filters; Cairo does not support gaussian blur. 3D
>transformations, we will not be able to not implement card flip animation.
>Never reach the same performance if using platform native frameworks (e.g.
>Direct2D on windows). Cairo will not die, but there is zero progress.
>- Vulkan support. Never with cairo. Pure OpenGL too (try to compile
>cairo-gl on mac, good luck!) There is a way to compile it with quartz
>support. As of version 2.7.9, *XQuartz does not provide support for
>high-resolution Retina displays to X11 apps*, which run in
>pixel-doubled mode on high-resolution displays. (
>https://bugs.freedesktop.org/show_bug.cgi?id=92777
><https://bugs.freedesktop.org/s

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Aliaksei Syrel]

t would be great if community could invest money and time in a
working and appropriate solution.

P.S. If we would not care, we would agree with you instantly and even not
bothered ourselves trying to spend time on finding cheap solution for such
a complex problem.

P.P.S Sorry for a long email :)

Cheers,
Alex

On 26 January 2017 at 21:10, Aliaksei Syrel <alex.sy...@gmail.com> wrote:

> Hi,
>
> Then we will need Cairo + SDL2 (that does not work for us) + Freetype2
> (for fonts) + Graphite (glyphs shaping technology in order to use them
> within vector graphics engine) + cross platform OpenGL / Vulkan
> context/device provider for hardware acceleration + implement Filters for
> effects (blur, lights, color matrix filters, etc...).
>
> Without all those technologies bloc WILL progress, from 80's to 00's.
> Still decades behind :)
>
> Cheers
>
> On Jan 26, 2017 20:40, "stepharong" <stephar...@free.fr> wrote:
>
>> I think that instead of investigating gtk (yet another library to bind
>> and carry around),
>> it would be smarter to have Sparta back-end using an accelerated Cairo +
>> pango.
>> Why? Because
>> - For example Cairo will not disappear in the future (here you
>> will tell me that it does not have all the full
>> features I think that Bloc should deliver Brick first and
>> focus on this because else it will stay a nice
>> experiment.)
>> - We do not have bench with an accelerated compiled version so no
>> idea if this is good enough.
>> - Cairo is about 1.5 mb vs 20Mb and it is packaged.
>>
>> I share the concerns of Esteban about the maintenance of such Mozz2d
>> bundling and he was pretty
>> clear with me, he will not maintain it nor take any responsibility about
>> pharo using it.
>>
>> So having a Cairo Sparta back-end would be a smart move.
>> Stef
>>
>>
>>
>>
>>
>> Hi,
>>>
>>> Thank you for the intensive set of issues you raised during the Bloc
>>> presentation. I think it is worthwhile addressing them more thoroughly, so
>>> let me start with the issue that seemed to have caused the most worries:
>>> Sparta & Moz2D.
>>>
>>> Please keep in mind that while I am involved to some extent in Bloc, the
>>> real credits for the current state go to Glenn and Alex.
>>>
>>> Moz2D (https://github.com/mozilla/moz2d, https://wiki.mozilla.org/Platf
>>> orm/GFX/Moz2D) offers an advanced backend and using it puts us on par
>>> with the rendering speed of a web browser, which is a significant added
>>> value over what we have now.
>>>
>>> However, as it was noted, it does come with a cost due to the fact that
>>> it is not available as standalone with only the features we are interested
>>> in. The vector graphics part is actually buildable out of the box. However,
>>> the text support needs to be extracted out of Moz2D, and this is where the
>>> patching scripts are used. The patches are there only for compilation
>>> purposes and not for features and they are applied automatically. You can
>>> see it here:
>>> https://github.com/syrel/Moz2D
>>>
>>> Alex updated recently the Moz2D version and it worked without problems.
>>> Of course, future changes in Moz2D might imply changes in this script as
>>> well, and this implies that we will need to maintain that script. And we
>>> could imagine applying these patches on the trunk of Moz2D to see if they
>>> work, and we can also imagine engaging with the Moz2D owners to see if we
>>> can find a middle ground.
>>>
>>> Now, let’s put this into perspective. We are currently using Athens and
>>> the Cairo backend. While Cairo is provided as a standalone library it has
>>> not seen significant advances since Mozzila shifted its focus towards
>>> Moz2D. So, sticking with it might not be an ideal strategy either.
>>>
>>> Furthermore, just like Athens, Sparta is an abstraction that allows us
>>> to switch the underlying backend should we need to. Until now we did not
>>> find a cross-platform backend that is as advanced and complete as Moz2D,
>>> but there is no reason to think that none other will appear in the future.
>>> Skia is an alternative but it is only a vector graphic engine without text
>>> support, so using it would imply to have another library for the text
>>> support.
>>>
>>> Sparta also comes with a reasonable set of tests that is aimed at
>>> testing the basic Moz2D functionality to make sure that the assumptions on
>>> top of which Sparta is built are correct.
>>>
>>> All in all, I think that the current situation is not ideal, but there
>>> is already enough engineering in place to actually make it work. And I
>>> definitely think that the potential it opens is rather significant.
>>>
>>> And, if more people look at the scripts, we might find even better and
>>> cheaper ways to express it.
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>> --
>>> www.tudorgirba.com
>>> www.feenk.com
>>>
>>> "We cannot reach the flow of things unless we let go."
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Using Opera's mail client: http://www.opera.com/mail/
>>
>>

Re: [Pharo-dev] [bloc] addressing the moz2d issue

[Aliaksei Syrel]

Hi,

Then we will need Cairo + SDL2 (that does not work for us) + Freetype2 (for
fonts) + Graphite (glyphs shaping technology in order to use them within
vector graphics engine) + cross platform OpenGL / Vulkan context/device
provider for hardware acceleration + implement Filters for effects (blur,
lights, color matrix filters, etc...).

Without all those technologies bloc WILL progress, from 80's to 00's. Still
decades behind :)

Cheers

On Jan 26, 2017 20:40, "stepharong"  wrote:

> I think that instead of investigating gtk (yet another library to bind and
> carry around),
> it would be smarter to have Sparta back-end using an accelerated Cairo +
> pango.
> Why? Because
> - For example Cairo will not disappear in the future (here you
> will tell me that it does not have all the full
> features I think that Bloc should deliver Brick first and
> focus on this because else it will stay a nice
> experiment.)
> - We do not have bench with an accelerated compiled version so no
> idea if this is good enough.
> - Cairo is about 1.5 mb vs 20Mb and it is packaged.
>
> I share the concerns of Esteban about the maintenance of such Mozz2d
> bundling and he was pretty
> clear with me, he will not maintain it nor take any responsibility about
> pharo using it.
>
> So having a Cairo Sparta back-end would be a smart move.
> Stef
>
>
>
>
>
> Hi,
>>
>> Thank you for the intensive set of issues you raised during the Bloc
>> presentation. I think it is worthwhile addressing them more thoroughly, so
>> let me start with the issue that seemed to have caused the most worries:
>> Sparta & Moz2D.
>>
>> Please keep in mind that while I am involved to some extent in Bloc, the
>> real credits for the current state go to Glenn and Alex.
>>
>> Moz2D (https://github.com/mozilla/moz2d, https://wiki.mozilla.org/Platf
>> orm/GFX/Moz2D) offers an advanced backend and using it puts us on par
>> with the rendering speed of a web browser, which is a significant added
>> value over what we have now.
>>
>> However, as it was noted, it does come with a cost due to the fact that
>> it is not available as standalone with only the features we are interested
>> in. The vector graphics part is actually buildable out of the box. However,
>> the text support needs to be extracted out of Moz2D, and this is where the
>> patching scripts are used. The patches are there only for compilation
>> purposes and not for features and they are applied automatically. You can
>> see it here:
>> https://github.com/syrel/Moz2D
>>
>> Alex updated recently the Moz2D version and it worked without problems.
>> Of course, future changes in Moz2D might imply changes in this script as
>> well, and this implies that we will need to maintain that script. And we
>> could imagine applying these patches on the trunk of Moz2D to see if they
>> work, and we can also imagine engaging with the Moz2D owners to see if we
>> can find a middle ground.
>>
>> Now, let’s put this into perspective. We are currently using Athens and
>> the Cairo backend. While Cairo is provided as a standalone library it has
>> not seen significant advances since Mozzila shifted its focus towards
>> Moz2D. So, sticking with it might not be an ideal strategy either.
>>
>> Furthermore, just like Athens, Sparta is an abstraction that allows us to
>> switch the underlying backend should we need to. Until now we did not find
>> a cross-platform backend that is as advanced and complete as Moz2D, but
>> there is no reason to think that none other will appear in the future. Skia
>> is an alternative but it is only a vector graphic engine without text
>> support, so using it would imply to have another library for the text
>> support.
>>
>> Sparta also comes with a reasonable set of tests that is aimed at testing
>> the basic Moz2D functionality to make sure that the assumptions on top of
>> which Sparta is built are correct.
>>
>> All in all, I think that the current situation is not ideal, but there is
>> already enough engineering in place to actually make it work. And I
>> definitely think that the potential it opens is rather significant.
>>
>> And, if more people look at the scripts, we might find even better and
>> cheaper ways to express it.
>>
>> Cheers,
>> Doru
>>
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "We cannot reach the flow of things unless we let go."
>>
>>
>>
>>
>>
>>
>
> --
> Using Opera's mail client: http://www.opera.com/mail/
>
>

Re: [Pharo-dev] memoized vs once

[Aliaksei Syrel]

Underscore.js names it also #memoize.
http://underscorejs.org/#memoize

Cheers

On Jan 26, 2017 00:15, "p...@highoctane.be"  wrote:

If one is doing any dynamic programming, the memoization term is pretty
natural.

https://youtu.be/OQ5jsbhAv_M?t=3m11s

Phil

On Wed, Jan 25, 2017 at 10:30 PM, Igor Stasenko  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.
>

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

[Aliaksei Syrel]

On 25 January 2017 at 16:02, Thierry Goubier 
 wrote:

> Yes, it goes a bit faster. But I stopped half way through the list: it is
> tuned a lot slower than I'm used to with Morphic.


Hehe :) Tuning is another story. Current implementation treats mouse wheel
and trackpad in the same way, which should not be the case of course.

Basically, If I compare the bloc class list to a Morphic class list
> scrolling variable speed example, I really have to work out hard the scroll
> wheel with Bloc... and, still, I'm not reaching the end of the list.


I made a video comparison of 3 list implementations that display all
smalltalk classes. I tried to scroll identically for all three cases and
covered almost the same distance with mouse wheel:
​
 Morphic-Bloc-Lists.mov

​
What morphic example did you use?
I would be also very very glad to know what DNUs and segfaults you get :)

Cheers,
Alex

Re: [Pharo-dev] [ANN] TechTack today 24/01/2017 16h UTC Bloc/Brick links

[Aliaksei Syrel]

Hi Thierry

Thanks for your testing effort!

 moz2D prerequisites do not install cleanly on ubuntu 16.04.

Exactly, it is hard to install many 32 dependencies on 64bit linux system.
(there is no solution for this). That is why it would be nice to have 64
bit VM for 64 bit linux :)
With 64bit vm there will be almost none additional dependencies required.

They look nice and smooth, scrolling is tuned at slow for long lists.

How do you scroll? Current scrolling behaviour is very simple while being
rather powerful. Speed increases if user continuously scrolls with mouse
wheel or touchpad. Faster you move your finger on touchpad or scroll more
frequent with mouse wheel than faster is scrolling speed.

It segfaults regularly when scrolling.

This might be unrelated to the library. Could you send crash dump?

 Do you have an example of scrolling where I can choose to scroll fast or
> slow depending on how I use the trackpad or scrollwheel? On Linux, the OS
> doesn't manipulate those events as Macs seems to be doing, so you need to
> code that.


This behaviour is a default one. Maybe problem is with SDL2 events? Video
would be great to understand how you scroll and how you expect it to be :)

Cheers,
Alex

Re: [Pharo-dev] FFICallback crashes windows spur i386 vm

[Aliaksei Syrel]

UPD:
Works with latest *Mac* VM
http://files.pharo.org/vm/pharo-spur32/mac/pharo-mac-i386-201701130756-83c0ef1.zip

Cheers,
Alex

On 13 January 2017 at 20:43, Aliaksei Syrel <alex.sy...@gmail.com> wrote:

> UPD:
> Works using 497 windows vm: http://files.pharo.org/vm/
> pharo-spur32/win/497.zip.
> Something was changed recently...
>
> Cheers,
> Alex
>
> On 13 January 2017 at 11:20, Peter Uhnak <i.uh...@gmail.com> wrote:
>
>> On Fri, Jan 13, 2017 at 11:01:42AM -0800, Aliaksei Syrel wrote:
>> > Hi Peter,
>> >
>> > Latest windows VMs produce crash dumps ;)
>>
>> Excellent! :)
>>
>> Peter
>>
>> >
>> > Cheers,
>> > Alex
>> >
>> > On 13 January 2017 at 10:57, Peter Uhnak <i.uh...@gmail.com> wrote:
>> >
>> > > On Fri, Jan 13, 2017 at 10:27:27AM -0800, Aliaksei Syrel wrote:
>> > > > Hi
>> > > >
>> > > > The following code crashes windows spur32 VM without crash.dmp:
>> > > > (crashes not only in case of int8, but ulong, int16/32 and so on...)
>> > >
>> > > I don't think that Windows produces crash dumps (or they are empty
>> files),
>> > > but maybe you can find some info in Event Viewer (start>run
>> "eventvwr.msc")
>> > > in Event Viewer > Windows Logs > Application.
>> > >
>> > > >
>> > > > Callback instantiation:
>> > > >
>> > > > createCallback
>> > > > >^ FFICallback
>> > > > >   signature: #(int8 (int8))
>> > > > >   block: [ :value | value ]
>> > > >
>> > > >
>> > > > C function:
>> > > >
>> > > > int8_t test(int8_t(*function)(int8_t), int8_t value) {
>> > > > >return function(value);
>> > > > > }
>> > > >
>> > > >
>> > > > FFI call:
>> > > >
>> > > > primCall: aCallback int8: aNumber
>> > > > >^ self ffiCall: #(int8 test(FFICallback aCallback, int8
>> aNumber))
>> > > >
>> > > >
>> > > > Test case:
>> > > >
>> > > > test
>> > > > >   self
>> > > > > assert: (self primCall: self createCallback int8: 0)
>> > > > > equals: 0
>> > > >
>> > > >
>> > > >
>> > > > Windows 10.
>> > > > VM from today:
>> > > > http://files.pharo.org/vm/pharo-spur32/win/pharo-win-
>> > > i386-201701130756-83c0ef1.zip
>> > > > Image 60343:
>> > > > http://files.pharo.org/image/60/60343.zip
>> > > >
>> > > > P.S. what is the best place to report FFI / Alien issues?
>> > > > P.P.S Iceberg works
>> > > >
>> > > > Cheers,
>> > > > Alex
>> > >
>> > >
>>
>>
>

Re: [Pharo-dev] FFICallback crashes windows spur i386 vm

[Aliaksei Syrel]

UPD:
Works using 497 windows vm:
http://files.pharo.org/vm/pharo-spur32/win/497.zip.
Something was changed recently...

Cheers,
Alex

On 13 January 2017 at 11:20, Peter Uhnak <i.uh...@gmail.com> wrote:

> On Fri, Jan 13, 2017 at 11:01:42AM -0800, Aliaksei Syrel wrote:
> > Hi Peter,
> >
> > Latest windows VMs produce crash dumps ;)
>
> Excellent! :)
>
> Peter
>
> >
> > Cheers,
> > Alex
> >
> > On 13 January 2017 at 10:57, Peter Uhnak <i.uh...@gmail.com> wrote:
> >
> > > On Fri, Jan 13, 2017 at 10:27:27AM -0800, Aliaksei Syrel wrote:
> > > > Hi
> > > >
> > > > The following code crashes windows spur32 VM without crash.dmp:
> > > > (crashes not only in case of int8, but ulong, int16/32 and so on...)
> > >
> > > I don't think that Windows produces crash dumps (or they are empty
> files),
> > > but maybe you can find some info in Event Viewer (start>run
> "eventvwr.msc")
> > > in Event Viewer > Windows Logs > Application.
> > >
> > > >
> > > > Callback instantiation:
> > > >
> > > > createCallback
> > > > >^ FFICallback
> > > > >   signature: #(int8 (int8))
> > > > >   block: [ :value | value ]
> > > >
> > > >
> > > > C function:
> > > >
> > > > int8_t test(int8_t(*function)(int8_t), int8_t value) {
> > > > >return function(value);
> > > > > }
> > > >
> > > >
> > > > FFI call:
> > > >
> > > > primCall: aCallback int8: aNumber
> > > > >^ self ffiCall: #(int8 test(FFICallback aCallback, int8
> aNumber))
> > > >
> > > >
> > > > Test case:
> > > >
> > > > test
> > > > >   self
> > > > > assert: (self primCall: self createCallback int8: 0)
> > > > > equals: 0
> > > >
> > > >
> > > >
> > > > Windows 10.
> > > > VM from today:
> > > > http://files.pharo.org/vm/pharo-spur32/win/pharo-win-
> > > i386-201701130756-83c0ef1.zip
> > > > Image 60343:
> > > > http://files.pharo.org/image/60/60343.zip
> > > >
> > > > P.S. what is the best place to report FFI / Alien issues?
> > > > P.P.S Iceberg works
> > > >
> > > > Cheers,
> > > > Alex
> > >
> > >
>
>

Re: [Pharo-dev] FFICallback crashes windows spur i386 vm

[Aliaksei Syrel]

Hi Peter,

Latest windows VMs produce crash dumps ;)

Cheers,
Alex

On 13 January 2017 at 10:57, Peter Uhnak <i.uh...@gmail.com> wrote:

> On Fri, Jan 13, 2017 at 10:27:27AM -0800, Aliaksei Syrel wrote:
> > Hi
> >
> > The following code crashes windows spur32 VM without crash.dmp:
> > (crashes not only in case of int8, but ulong, int16/32 and so on...)
>
> I don't think that Windows produces crash dumps (or they are empty files),
> but maybe you can find some info in Event Viewer (start>run "eventvwr.msc")
> in Event Viewer > Windows Logs > Application.
>
> >
> > Callback instantiation:
> >
> > createCallback
> > >^ FFICallback
> > >   signature: #(int8 (int8))
> > >   block: [ :value | value ]
> >
> >
> > C function:
> >
> > int8_t test(int8_t(*function)(int8_t), int8_t value) {
> > >return function(value);
> > > }
> >
> >
> > FFI call:
> >
> > primCall: aCallback int8: aNumber
> > >^ self ffiCall: #(int8 test(FFICallback aCallback, int8 aNumber))
> >
> >
> > Test case:
> >
> > test
> > >   self
> > > assert: (self primCall: self createCallback int8: 0)
> > > equals: 0
> >
> >
> >
> > Windows 10.
> > VM from today:
> > http://files.pharo.org/vm/pharo-spur32/win/pharo-win-
> i386-201701130756-83c0ef1.zip
> > Image 60343:
> > http://files.pharo.org/image/60/60343.zip
> >
> > P.S. what is the best place to report FFI / Alien issues?
> > P.P.S Iceberg works
> >
> > Cheers,
> > Alex
>
>

[Pharo-dev] FFICallback crashes windows spur i386 vm

[Aliaksei Syrel]

Hi

The following code crashes windows spur32 VM without crash.dmp:
(crashes not only in case of int8, but ulong, int16/32 and so on...)

Callback instantiation:

createCallback
>^ FFICallback
>   signature: #(int8 (int8))
>   block: [ :value | value ]


C function:

int8_t test(int8_t(*function)(int8_t), int8_t value) {
>return function(value);
> }


FFI call:

primCall: aCallback int8: aNumber
>^ self ffiCall: #(int8 test(FFICallback aCallback, int8 aNumber))


Test case:

test
>   self
> assert: (self primCall: self createCallback int8: 0)
> equals: 0



Windows 10.
VM from today:
http://files.pharo.org/vm/pharo-spur32/win/pharo-win-i386-201701130756-83c0ef1.zip
Image 60343:
http://files.pharo.org/image/60/60343.zip

P.S. what is the best place to report FFI / Alien issues?
P.P.S Iceberg works

Cheers,
Alex

Re: [Pharo-dev] [Moose-dev] Too frequent crashes :-(

[Aliaksei Syrel]

According to crash.dmp TRMorph>drawOn: draws an image using
FormCanvas>>#image:at:sourceRect:rule:  at a coordinate represented by a
Float point.
Try to round it to integer point.

Cheers,
Alex

On 16 December 2016 at 16:34, Alexandre Bergel 
wrote:

> Hi!
>
> Vincent and I are experiencing many crashes from GrafPort>copyBits. It
> crashes every couple of minutes.
>
> I know that not much can be done so far. Stability is my biggest concern
> with Pharo :-(
> I use the latest VM.
>
> Cheers,
> Alexandre
>
>
>
>
>
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
> ___
> Moose-dev mailing list
> moose-...@list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev
>
>

Re: [Pharo-dev] Generate accessors refactoring

[Aliaksei Syrel]

Could we deselect check box by default in Nautilus if refactoring suggests
instVar1 / instVar1?
Every time have to go through the list and deselect...

Cheers,
Alex

On 8 December 2016 at 14:11, Eliot Miranda  wrote:

> Hi Nicolas,
>
> On Dec 8, 2016, at 1:16 AM, Nicolas Passerini 
> wrote:
>
> Let me recapitulate a little.
> A) What to do in case that a method with same selector already exists in
> the same class?
> So far I think we've come up with four ideas:
> 1. Create with an alternative name such as instVar1 / instVar1:
> 2. Create with an alternative name but ask the user what the name should
> be.
> 3. Replace existing method with simple accessor.
> 4. Do nothing.
>
>
> To be clear, you don't mean Do Nothing; you mean Issue an Error and Abort
> the Refactoring right?
>
>
> I think that the last one is the best alternative and should be the
> default action. Let me analyze the others:
> 1. Is the current behavior, but I always end up deleting the method, I
> can't think of a situation in which I want to keep a method named #name1 .
> I know that there was a lot of thinking on top of this ideas, but even so
> I think that we can (should) rethink things once in a while.
>
> 2. A little better, because lets me select a name better than #name1.
> Still I do not like it, because this means that I have a Class with
> - an instance variable 'name'
> - a method #name which is not the accessor for 'name' inst var.
> -  and an accessor which is named in another way
>
> I think this can happen in two situations:
> - The original #name method is in fact a (smarter) accessor (i.e., for
> example it provides a lazy initialization). In this case the best action is
> 4 => do nothing, accessor already exists, do not provide a new one.
> - The original #name does something else, that maybe has nothing to do
> with the variable name... in this case, I think the best is aborting the
> refactor. I am not proposing that refactoring browser should abort the
> refactor automatically, probably not, but that is what I would do as user:
> my class has a weird name clash, so I should rename either the inst var or
> the method, it has no automatic solution.
>
> I am not sure about how the "generate accessors" could help me coping with
> name clashes, but I do not like generating accessor with another name
> different from the inst var name is a good idea. We could have this as an
> option to the user, but should not be the default.
>
> 3. This is really dangerous, we shouldn't do it. I am not sure if someone
> would like to have this as a (non default) option.
>
>
> B) What if the colliding method is in a superclass?
> Well, pretty much the same but:
> - in option 3 instead of replacing a method you could override it.
> - the method in the superclass could not be a "smarter accessor" unless
> you are trying to create accessors in subclass for an inst var in the
> superclass... I do not like it. So I'd consider it allways as a name clash.
>
> Then I think that the best option is still do nothing (option 4). You
> could offer to create method with another name as alternative (option 2)...
> but I still think that this kind of name "coincidences" may introduce bugs
> in the future and should be avoided.
>
> C) Colliding methods in subclasses.
> Here we have a more subtle situation because the existing method could be
> a smarter accessor, that even could have its motivation to be there (for
> example because initialization code only is useful for one subclass).
>
> I still think that doing nothing could be a safe solution, better than
> creating it with an alternative name (but we could allow it also).
>
> Here we could think also about writing the accessor, because it will not
> override preexistent behavior. But we have to think about a few situations:
> - Easy, if any of the colliding methods (they could be serveral one for
> each subclass) is not a smarter accessor... we have name clashes and we
> cannot do anything.
> - If all colliding methods are smart accessors, we could create one in the
> superclass, provided that there exists at least one subclass which does not
> provide its own implementation.
>
>
> Of course there is not precise way of determining if a preexistent method
> can be considered as a smarter accessor or not... so we only can let the
> user decide.
>
> To resume:
> - Doing nothing will be the best default as it is suitable for all cases,
> and can not do any harm.
> - Creating methods with alternative names could be optional, but shouldn't
> be default. In this case I prefer to ask the user for a name instead of
> creating one automatically.
> - Creating the method even in case of collision can be dangerous... I am
> not sure if we should even allow it as an option.
>
> 2016-12-07 0:03 GMT+01:00 Ben Coman :
>
>> How about mostly keeping the existing behaviour, but default to
>> collisions being deselected?
>> Then at least you don't 

Re: [Pharo-dev] Drastically improving the messageNotUnderstood title

[Aliaksei Syrel]

The fact that method does not exist does not necessarily mean that object
does not understand a message ;)

First of all you will never see the word message mentioned in those
> languages you mentioned

Indeed in C/Java/etc there is no such word message, that is why you can
find word "method" in parentheses to the right from word "message"
(actually second word in first sentence).

In case of two other mentioned languages Smalltalk/Ruby word "message" is
common. Do you agree that it is the case in Smalltalk? ;)
For the Ruby I would like to refer to official documentation,
especially method_missing
hook (analogue of doesNotUnderstand: in Pharo).

https://ruby-doc.org/core-2.1.0/BasicObject.html#method-i-method_missing (first
sentence)
Invoked by Ruby when *obj* is sent* a message it cannot handle*.

Cheers,
Alex

On 8 December 2016 at 12:34, Dimitris Chloupis <kilon.al...@gmail.com>
wrote:

> First of all you will never see the word message mentioned in those
> languages you mentioned
> Second the word , understood, says nothing about the nature of the problem
> to a beginner
>
> Is it that the method does not exist ?
> Or is it that method exists but message does not ?
> Or is it that the method does something it should not ?
> Or is the VM that has problem executing the method ?
>
>
>
>
> On Thu, 8 Dec 2016 at 11:27, Aliaksei Syrel <alex.sy...@gmail.com> wrote:
>
>> "Message(method) does not exist" happens in C/Java/etc when we *call* a
>> method.
>> "Message not understood by an object" happens in Smalltalk/Ruby when we
>> *send* a message.
>>
>> I like this conceptual distinguishment between calling a method and
>> sending a message.
>>
>> Cheers,
>> Alex
>>
>

Re: [Pharo-dev] Drastically improving the messageNotUnderstood title

[Aliaksei Syrel]

"Message(method) does not exist" happens in C/Java/etc when we *call* a
method.
"Message not understood by an object" happens in Smalltalk/Ruby when we
*send* a message.

I like this conceptual distinguishment between calling a method and sending
a message.

Cheers,
Alex

Re: [Pharo-dev] :: Separator in class names

[Aliaksei Syrel]

This thread has a huge discussion potential :)
*grabs popcorn*

On 8 December 2016 at 01:47, Torsten Bergmann  wrote:

> Hi,
>
> due to the absence of a namespace solution we today often prefix classes
> with one, two or three letters.
> You all know prefixes like "Zn", "Zdc", "GLM", "Tx", "WA", ... to avoid
> conflicting names.
>
> I would like to have a "::" separator within the class name to better
> distinguish
> the class name from the prefix and increase readability at the same time.
> SmalltalkMT
> had this solution in alignment with C++ and I really liked working with it.
> So much that I would like to see it in Pharo too - maybe also as a base
> for future Namespace
> additions.
>
> So I modified the #isValidGlobalName in Pharo 6.0 like mentioned below to
> allow and support
> the :: notation for classes. After that I can create classes like:
>
>   Seaside::Component
>   Core::Boolean
>   Model::Person
>   GLM::BrickListModel
>   Tx::FontAttribute
>
> so far without any problem.
>
> Do you think
>  - there will be places where this conflicts or creates hazzles (tools,
> metacello, ...)
>  - if it would be a good idea to add this to the default image?
>
> Thanks for feedback.
>
> Thx
> T.
>
> 
> --
> isValidGlobalName
>
> self ifEmpty: [ ^ false ].
>
> "reserverd default names"
> self = 'NameOfSubclass' ifTrue: [ ^ false ].
> self = 'TNameOfTrait' ifTrue: [ ^ false ].
>
> (self occurrencesOf: $:) = 2 ifTrue: [
> ^(self splitOn: '::') allSatisfy: [: part | part
> isValidGlobalName ]
> ].
>
> ^ Character supportsNonASCII
> ifTrue: [
> (self first isLetter
> and: [self first isUppercase])
> and: [ self allSatisfy: [:character |
> character isAlphaNumeric
> or: [ character = $_ 
> ifFalse: [
> (self first between: $A and: $Z) and: [
> self allSatisfy: [:character |
> (character between: $a and: $z)
> or: [
> (character between: $A and: $Z)
> or: [
> (character between: $0 and: $9)
> or: [
> character = $_]]
>
>

Re: [Pharo-dev] Generate accessors refactoring

[Aliaksei Syrel]

+1
super annoying!

On Dec 6, 2016 11:10, "Denis Kudriashov"  wrote:

> Hi.
>
> There is very annoying logic of accessors refactoring.
> For example imaging your class already has getter for variable #myInstVar
> but with some extra code instead of simple return. For example it could be
> lazy initialization:
>
>
> MyClass>>myInstVar
>^myInstVar ifNil: [#someValue]
>
>
> In that case accessors generator will suggest you new getter method
> #myInstVar*1. *
> I really doubt that anybody accept generation of such method.
> I always remove it from changes list which is very annoying.
>
> Am I alone about it? Can we remove this logic?
>
> Best regards,
> Denis
>

Re: [Pharo-dev] Bloc: Ominous Black External Window

[Aliaksei Syrel]

I also experience the same issue on mac time to time.
Situation is the same as with previous implementation based on OSWindow.

Cheers,
Alex

On 2 December 2016 at 17:27, Sean P. DeNigris  wrote:

> Tudor Girba-2 wrote
> > Could you describe the situation
>
> There was no clear cause. While playing with the examples, suddenly when
> Bloc opened an external window, the contents were black, and existing
> windows were uncloseable via the title bar button.
>
>
> Tudor Girba-2 wrote
> > the concrete path that fixed it
>
> BlUniverse reset
>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/Bloc-Omi
> nous-Black-External-Window-tp4925545p4925583.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] Bloc: Problems Running

[Aliaksei Syrel]

Hi Sean

I would really like to help you.
Could you explain why you want to install #git:development?

If you don't know what it means install User version of Bloc, as described
in INSTALL.md

Metacello new
   baseline:'Bloc';
   repository: 'github://pharo-graphics/Bloc/src';
   load:#core

Do you find installation guide hard to read or understand?
We are trying our best to provide a smooth user experience. Your feedback
can help make Bloc better.

Thanks,
Alex

On 29 November 2016 at 06:02, Sean P. DeNigris <s...@clipperadams.com>
wrote:

> Aliaksei Syrel wrote
> > Please refer to
> > https://github.com/pharo-graphics/Bloc/blob/master/INSTALL.md in order
> to
> > install bloc.
>
> $ wget -O- https://goo.gl/HQAPI5 | bash
> -> Oops, no wget on Mac
> $ curl https://goo.gl/HQAPI5 | bash
> -> line 1: syntax error near unexpected token `newline'... `'
> $ curl
> https://raw.githubusercontent.com/pharo-graphics/Bloc/master
> /scripts/get-dev
> | bash
> -> Still no wget :/
> $ curl http://get.pharo.org/60+vm | bash
> $ ./pharo Pharo.image eval --save "Metacello new
> baseline:'Bloc';repository:'github://pharo-graphics/Bloc/src
> ';load:#git:development."
> "Error: External module not found" from LGitLibrary>>libgit2_init
>
> ugh...
>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/Bloc-Pro
> blems-Running-tp4924930p4925076.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] two question about fasttable

[Aliaksei Syrel]

>
> Called by the table view to return the data object associated with the
> specified row and column.

https://developer.apple.com/reference/appkit/nstableviewdatasource/1533674-tableview

Cheers,
Alex

On 29 November 2016 at 10:44, Aliaksei Syrel <alex.sy...@gmail.com> wrote:

>
> On 29 November 2016 at 10:39, Esteban Lorenzano <esteba...@gmail.com>
> wrote:
>
>> not true.
>> it returns an NSView.
>>
>
> Could you name a method (send a link to a documentation) that is
> implemented by DataSource and returns an NSView?
>
> According to documentation NSView for an item at row/column index is
> created and returned by NSTableView:
> https://developer.apple.com/reference/appkit/nstableview/1528831-view
>
> I didn't find any NSView related method in DataSource. Am I looking in a
> wrong place?
>
> Cheers,
> Alex
>

Re: [Pharo-dev] two question about fasttable

[Aliaksei Syrel]

On 29 November 2016 at 10:39, Esteban Lorenzano  wrote:

> not true.
> it returns an NSView.
>

Could you name a method (send a link to a documentation) that is
implemented by DataSource and returns an NSView?

According to documentation NSView for an item at row/column index is
created and returned by NSTableView:
https://developer.apple.com/reference/appkit/nstableview/1528831-view

I didn't find any NSView related method in DataSource. Am I looking in a
wrong place?

Cheers,
Alex

Re: [Pharo-dev] two question about fasttable

[Aliaksei Syrel]

On 29 November 2016 at 10:14, Esteban Lorenzano  wrote:

> And DataSource is another stuff in Cocoa, from where I borrowed the
> design: https://developer.apple.com/reference/appkit/nstableviewdatasource
>
>

I know :)
However, implementation of FastTable does not correspond to Cocoa design.

A table view does not store its own data; it retrieves *data values* as
> needed *from a data source* to which it has a weak reference

https://developer.apple.com/reference/appkit/nstableview
This is where misconception begins. In Cocoa data source acts as real data
source, it returns Object, not Morph! At the same time DataSource in
FastTable returns Morphs.

Naming in Cocoa is correct and I am not arguing about it :) DataSource in
FastTable != DataSource in Cocoa.

Cheers,
Alex

Re: [Pharo-dev] two question about fasttable

[Aliaksei Syrel]

Sorry not souse, but a source :D

On 29 November 2016 at 09:58, Aliaksei Syrel <alex.sy...@gmail.com> wrote:

> "DataSource" is responsible for providing visual elements that represent
> items in a data set.
>
> I don't see how word "Store" fits here, because DataSource does not store
> anything. DataSource is also not the best name since it is not a data
> source itself.
> An object that is now called DataSource, basically just knows a single
> function that from mathematical point of view can be defined as follows:
> f: Object -> Morph . You see, it is a *mapping, not a souse or store.*
>
> Cheers,
> Alex
>
> On 29 November 2016 at 09:44, Denis Kudriashov <dionisi...@gmail.com>
> wrote:
>
>>
>> 2016-11-29 9:35 GMT+01:00 Esteban Lorenzano <esteba...@gmail.com>:
>>
>>> yes, something like TableCellSource or TableCellProvider is more
>>> intention revealing.
>>>
>>>
>>> No, because is not *just* a cell provider.
>>> TableDataSource, TableStore, TableProvider, yes.
>>>
>>> I kind of like “TableStore”.
>>
>>
>> And if we have TableMorph then this guy should be TableMorphStore IMO.
>>
>
>

Re: [Pharo-dev] two question about fasttable

[Aliaksei Syrel]

"DataSource" is responsible for providing visual elements that represent
items in a data set.

I don't see how word "Store" fits here, because DataSource does not store
anything. DataSource is also not the best name since it is not a data
source itself.
An object that is now called DataSource, basically just knows a single
function that from mathematical point of view can be defined as follows:
f: Object -> Morph . You see, it is a *mapping, not a souse or store.*

Cheers,
Alex

On 29 November 2016 at 09:44, Denis Kudriashov  wrote:

>
> 2016-11-29 9:35 GMT+01:00 Esteban Lorenzano :
>
>> yes, something like TableCellSource or TableCellProvider is more
>> intention revealing.
>>
>>
>> No, because is not *just* a cell provider.
>> TableDataSource, TableStore, TableProvider, yes.
>>
>> I kind of like “TableStore”.
>
>
> And if we have TableMorph then this guy should be TableMorphStore IMO.
>

Re: [Pharo-dev] Bloc: Problems Running

[Aliaksei Syrel]

Hi

Bloc requires an additional library that is not shipped with VM by default
(that is why you get module not found error). Please refer to
https://github.com/pharo-graphics/Bloc/blob/master/INSTALL.md in order to
install bloc.

Cheers
Alex

On Nov 28, 2016 03:49, "Sean P. DeNigris"  wrote:

> From Launcher, I tried to expand the v0.11 tree from the Contribution
> Jenkins, but got: "downloadFailureForUrl:
> https://ci.inria.fr/pharo-contribution/job/Bloc/PHARO=
> 60,VERSION=v0.11,VM=vm,label=pharo-contribution-ubuntu16-
> 04/lastSuccessfulBuild//api/json?tree=artifacts%5BrelativePath%5D".
> Then I downloaded the "master" artifact and on image launch, got "Error:
> External module not found" for SqueakFFIPrims even though it's listed as a
> builtin module in the System Reporter. I got the same error when I evaled
> "BlSpace new show". The vm is a recent download from get.pharo.org/vm50
>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/Bloc-
> Problems-Running-tp4924930.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] [Vm-dev] Removing most of the windowing code

[Aliaksei Syrel]

Thanks Ronie!
You are doing a great job! :)

Cheers,
Alex

On 24 November 2016 at 15:06, Ronie Salgado  wrote:

> you cannot unilaterally do this.
>> I hate autoconf too, but in VM list we have a general agreement on how to
>> manage the VM build process, and unless you manage to convince the rest of
>> people working there (and specially Eliot, who works there more than the
>> rest), you have literally zero chance this will be adopted (and then, your
>> work will be a general lose of time…).
>> In any case, you have my vote :)
>>
> This was something that I did for quickly testing and trying to remove the
> windowing code. I also did this, because the building system is not working
> all of the time in my linux machine. The scripts for loading the VMMaker
> image are most of the time not working at all in Linux. I got frustrated by
> not being able on keep working on Lowcode for supporting the 64 bits
> version, because of these problems.
>
> Anyway, I do not care if this part gets integrated or not, as long as I
> can keep working on my stuff, and I don't have a bunch of manully written
> scripts in build.*/* . As long as there is a single script that can be
> configured for each target or flavour of the VM I am okay with it.
>
> Now I will document these scripts:
>
> For setting the flavour of the VM, there are the following options
> - SPUR_OBJECT_MODEL (On by default)
> - SISTA_OPTIMIZER (Off by default)
> - PHARO_BRANDING (On by default)
> - COG_JIT(On by default. If off, it will build a stack interpreter only VM)
>
> There are platform specific check for choosing whether to build a 64 bits
> VM or not. When building in a x86_64 systems, there is the
> BUILD_I386_VERSION option (Off by default) which will set the appropiate
> flags for building a 32 bits VM in a 64 bits system (-m32)
>
> These options are used for making a string with the vm sources
> direction(src ,stacksrc, spursrc, etc) and for selecting the sources of the
> vm. In this experimental branch I am moving some of the sources at
> platform/ barest minimum code for compiling the VM. By the end of this, I should
> probably move back the platform specific sources into their original
> locations.
>
> The plugins to build with the VM are defined in Plugins.cmake (
> https://github.com/ronsaldo/opensmalltalk-vm/blob/
> MinimalisticHeadless/Plugins.cmake)
>
> Most of the time, adding a plugin is just a matter calling a macro:
>
>> # Basic internal plugins
>> add_vm_plugin_auto(FilePlugin INTERNAL)
>> add_vm_plugin_auto(LargeIntegers INTERNAL)
>> add_vm_plugin_auto(LocalePlugin INTERNAL)
>> add_vm_plugin_auto(MiscPrimitivePlugin INTERNAL)
>> add_vm_plugin_auto(SecurityPlugin INTERNAL)
>> add_vm_plugin_auto(SocketPlugin INTERNAL)
>>
>> add_vm_plugin_auto(B2DPlugin INTERNAL)
>> add_vm_plugin_auto(BitBltPlugin INTERNAL)
>>
>> add_vm_plugin_auto(FloatArrayPlugin INTERNAL)
>> add_vm_plugin_auto(FloatMathPlugin INTERNAL)
>> add_vm_plugin_auto(Matrix2x3Plugin INTERNAL)
>>
>> # Basic external plugins
>> add_vm_plugin_auto(SurfacePlugin EXTERNAL)
>>
>
> For more selective plugins, such as the SqueakFFIPrims plugin there is the
> add_vm_plugin_sources macro:
>
>> add_vm_plugin_sources(SqueakFFIPrims EXTERNAL ${SqueakFFIPrims_Sources})
>
>
> Later I will add another macro for linking a library with a plugin, which
> will perform the correct action depending whether the Plugin is internal or
> external. The macros for building a plugin add an option for specifying
> whether to build or not a plugin (e.g: BUILD_PLUGIN_FilePlugin,
> BUILD_PLUGIN_FT2Plugin).
>
> For building the a default VM using cmake, the only commands are required
> in the top level source directory:
>
>> mkdir build_dir
>> cd build_dir
>> cmake ..
>> make
>>
>
> For choosing interactively which options to enable or not, it is possible
> to use cmake-gui instead of cmake in the above sequence of commands. The
> built VM will be placed at build_dir/dist
>
> Currently, I am not using the cmake configure capabilties for generating
> config.h and generating the HAVE_*_H defines. Later I will implement this,
> but taking special care in supporting the cross compilation scenario, where
> it is not possible to execute compiled program for probing the system for
> things such as sizeof(void*).
>
> Could you explain more what traditional display backend means? Because I
>> am probably out of domain but want to know more.
>>
> If the SUPPORT_TRADITIONAL_DISPLAY cmake option is enabled, and cmake
> finds SDL2 (it will look for the SDL2 libraries using the names SDL2-2.0
> SDL2), then a non-headless VM will be built using
> sqPlatformSpecific-SDL2Window.c ( https://github.com/ronsaldo/
> opensmalltalk-vm/blob/MinimalisticHeadless/minheadless/source/
> sqPlatformSpecific-SDL2Window.c ) instead of
> sqPlatformSpecific-NullWindow.c ( https://github.com/ronsaldo/
> opensmalltalk-vm/blob/MinimalisticHeadless/minheadless/source/
> sqPlatformSpecific-NullWindow.c ).
>
> This 

Re: [Pharo-dev] About ~= and ~~

[Aliaksei Syrel]

Hi

It is been a while...
So, do we want to replace ~~ with a primitive? :)

Cheers
Alex



--
View this message in context: 
http://forum.world.st/About-and-tp3898409p4924391.html
Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

[Aliaksei Syrel]

On 10 November 2016 at 17:41, Sven Van Caekenberghe  wrote:

> 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 is why it is Big O notation (upper bound / worst case) ;)

Re: [Pharo-dev] Breaking the 4GB barrier with Pharo 6 64-bit

[Aliaksei Syrel]

> 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.

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"  wrote:

>
>
> On 10 November 2016 at 11:42, Tudor Girba  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] why sparta depends on Taskit?

[Aliaksei Syrel]

Hi

It is a library :) Even that there is an important difference between
plugin and library we always refer to library in this thread.

Cheers
Alex

On Nov 6, 2016 22:31, "Esteban Lorenzano" <esteba...@gmail.com> wrote:

>
> > On 6 Nov 2016, at 21:47, Tudor Girba <tu...@tudorgirba.com> wrote:
> >
> > Hi,
> >
> >> On Nov 6, 2016, at 9:43 PM, stepharo <steph...@free.fr> wrote:
> >>
> >> I tried to open the image that glenn gave me and I can browse the code
> (I got an FFI problem due to the fact that the lib is not present).
> >>
> >> I tried and I could open the image from the ci with the vm glenn sent
> me.
> >>
> >> So I will update my vm.
> >
> > Thanks!
> >
> > So, the default Pharo VM does not have the Moz2D plugin, and likely that
> is what Glenn gave you. Could you try with that VM to run 2 examples? I
> still have a funky issue with my machine that I can only run one example,
> and then I get a black screen for the second one.
>
> why do you need a plugin and not just a regular library?
>
> Esteban
>
> >
> > Cheers,
> > Doru
> >
> >> Stef
> >>
> >>
> >>
> >> Le 6/11/16 à 20:19, Tudor Girba a écrit :
> >>> Hi,
> >>>
> >>> It does not work to run the Bloc examples with the regular VM, but it
> does work to browse the code. Stef is saying that he cannot browse code in
> the Bloc image.
> >>>
> >>> This is a significant problem, but I just do not see why this is so.
> So, it would be very useful for us to learn where this problem could come
> from.
> >>>
> >>> Doru
> >>>
> >>>
> >>>> On Nov 6, 2016, at 7:01 PM, Aliaksei Syrel <alex.sy...@gmail.com>
> wrote:
> >>>>
> >>>> Hi
> >>>>
> >>>> Just taking Bloc image from CI does not work. Don't forget that you
> need Sparta plugin (libMoz2D.dylib/DLL/so). I didn't find a way how to ship
> plugin with image, sorry...
> >>>>
> >>>> It can be downloaded from bintray https://bintray.com/syrel/
> Moz2D/libMoz2D.
> >>>>
> >>>> Cheers
> >>>> Alex
> >>>>
> >>>>
> >>>> On Nov 6, 2016 4:58 PM, "Tudor Girba" <tu...@tudorgirba.com> wrote:
> >>>> Hi,
> >>>>
> >>>> I think there are a couple of thinks that are mixed up.
> >>>>
> >>>> First, the image from CI:
> >>>> - download the latest image built on October 12 on Jenkins:
> >>>> https://ci.inria.fr/pharo-contribution/job/Bloc/PHARO=
> 60,VERSION=development,VM=vm/lastSuccessfulBuild/artifact/Bloc.zip
> >>>> - run it either with the stable of the latest VM
> >>>> ==> you should get no crash when opening the image (I just checked
> again)
> >>>>
> >>>> The code loading is a bit strange. I just tried and I do now know why
> this does not work from the command line on Mac. For me it somehow hanged
> while loading PetitCSS. There is something strange with Metacello and
> projects that depend on Glamour that I could not quite fully understand yet
> and I am looking at it since a month. Dale, I need your help, but I will
> follow up on this :).
> >>>>
> >>>> At the same time, I can reliably load the code using this script from
> a fresh Pharo image and the latest VM:
> >>>>
> >>>> Gofer it
> >>>>   smalltalkhubUser: 'Pharo' project: 'Bloc';
> >>>>   configuration;
> >>>>   loadDevelopment.
> >>>>
> >>>> Can you please try this one?
> >>>>
> >>>> Cheers,
> >>>> Doru
> >>>>
> >>>>
> >>>>
> >>>>> On Nov 6, 2016, at 11:24 AM, stepharo <steph...@free.fr> wrote:
> >>>>>
> >>>>> I got to the ci and I click on the image and download and drop it on
> my vm=> crash.
> >>>>> Why doing a video?
> >>>>>
> >>>>> open a shell
> >>>>>
> >>>>>wget -O - http://get.pharo.org/60+vm | bash
> >>>>> ./pharo Pharo.image config http://www.smalltalkhub.com/
> mc/Pharo/Bloc/main ConfigurationOfBloc --install=development
> >>>>>
> >>>>> And it fails loading taskit.
> >>>>>
> >>>>> Stef
> >>>>

Re: [Pharo-dev] why sparta depends on Taskit?

[Aliaksei Syrel]

Hi

Just taking Bloc image from CI does not work. Don't forget that you need
Sparta plugin (libMoz2D.dylib/DLL/so). I didn't find a way how to ship
plugin with image, sorry...

It can be downloaded from bintray https://bintray.com/syrel/Moz2D/libMoz2D.

Cheers
Alex

On Nov 6, 2016 4:58 PM, "Tudor Girba" <tu...@tudorgirba.com> wrote:

> Hi,
>
> I think there are a couple of thinks that are mixed up.
>
> First, the image from CI:
> - download the latest image built on October 12 on Jenkins:
> https://ci.inria.fr/pharo-contribution/job/Bloc/PHARO=
> 60,VERSION=development,VM=vm/lastSuccessfulBuild/artifact/Bloc.zip
> - run it either with the stable of the latest VM
> ==> you should get no crash when opening the image (I just checked again)
>
> The code loading is a bit strange. I just tried and I do now know why this
> does not work from the command line on Mac. For me it somehow hanged while
> loading PetitCSS. There is something strange with Metacello and projects
> that depend on Glamour that I could not quite fully understand yet and I am
> looking at it since a month. Dale, I need your help, but I will follow up
> on this :).
>
> At the same time, I can reliably load the code using this script from a
> fresh Pharo image and the latest VM:
>
> Gofer it
>smalltalkhubUser: 'Pharo' project: 'Bloc';
>configuration;
>loadDevelopment.
>
> Can you please try this one?
>
> Cheers,
> Doru
>
>
>
> > On Nov 6, 2016, at 11:24 AM, stepharo <steph...@free.fr> wrote:
> >
> > I got to the ci and I click on the image and download and drop it on my
> vm=> crash.
> > Why doing a video?
> >
> > open a shell
> >
> > wget -O - http://get.pharo.org/60+vm | bash
> > ./pharo Pharo.image config http://www.smalltalkhub.com/
> mc/Pharo/Bloc/main ConfigurationOfBloc --install=development
> >
> > And it fails loading taskit.
> >
> > Stef
> >
> >
> >
> >
> > Le 6/11/16 à 11:01, Aliaksei Syrel a écrit :
> >> The best would be if you could make a video of how you install Bloc and
> send to Glenn. Because it works for us and for Travis CI. Sound
> like you face a strange and not so easy to catch issue.
> >>
> >> Cheers
> >> Alex
> >>
> >>
> >> On Nov 5, 2016 6:54 PM, "stepharo" <steph...@free.fr> wrote:
> >> why sparta depends on Taskit?
> >>
> >>
> >> Since I cannot load it I cannot try to understand. I find strange that
> a graphical canvas depends on a concurrent task management system.
> >>
> >> I tried to follow the instruction given by glenn and it failed. So so
> far I could not see any recent versions of Bloc.
> >>
> >> I do not understand why the image produced by the jenkins job crashes
> my vm.
> >>
> >>
> >> Stef
> >>
> >>
> >> wget -O - http://get.pharo.org/60+vm | bash
> >> ./pharo Pharo.image config http://www.smalltalkhub.com/
> mc/Pharo/Bloc/main ConfigurationOfBloc --install=development
> >>
> >>
> >> just failed yesterday for me.
> >>
> >>
> >
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "What we can governs what we wish."
>
>
>
>
>
>

Re: [Pharo-dev] why sparta depends on Taskit?

[Aliaksei Syrel]

The best would be if you could make a video of how you install Bloc and
send to Glenn. Because it works for us and for Travis CI. Sound like you
face a strange and not so easy to catch issue.

Cheers
Alex

On Nov 5, 2016 6:54 PM, "stepharo"  wrote:

> why sparta depends on Taskit?
>
>
> Since I cannot load it I cannot try to understand. I find strange that a
> graphical canvas depends on a concurrent task management system.
>
> I tried to follow the instruction given by glenn and it failed. So so far
> I could not see any recent versions of Bloc.
>
> I do not understand why the image produced by the jenkins job crashes my
> vm.
>
>
> Stef
>
>
> wget -O - http://get.pharo.org/60+vm | bash
> ./pharo Pharo.image config http://www.smalltalkhub.com/mc/Pharo/Bloc/main
> ConfigurationOfBloc --install=development
>
>
> just failed yesterday for me.
>
>
>

Re: [Pharo-dev] why sparta depends on Taskit?

[Aliaksei Syrel]

Hi

Sparta definitely does not depend on TaskIt :) I have no idea what is it.

Cheers
Alex

On Nov 5, 2016 6:54 PM, "stepharo"  wrote:

> why sparta depends on Taskit?
>
>
> Since I cannot load it I cannot try to understand. I find strange that a
> graphical canvas depends on a concurrent task management system.
>
> I tried to follow the instruction given by glenn and it failed. So so far
> I could not see any recent versions of Bloc.
>
> I do not understand why the image produced by the jenkins job crashes my
> vm.
>
>
> Stef
>
>
> wget -O - http://get.pharo.org/60+vm | bash
> ./pharo Pharo.image config http://www.smalltalkhub.com/mc/Pharo/Bloc/main
> ConfigurationOfBloc --install=development
>
>
> just failed yesterday for me.
>
>
>

Re: [Pharo-dev] Instructions for Pharo 6 64bits

[Aliaksei Syrel]

I faced an issue that FFI calls fail with arguments of type size_t  or the
value that was passed to C function was completely wrong. For example you
pass 1 but get 29834693165

Cheers,
Alex

On 28 October 2016 at 14:22, Thierry Goubier 
wrote:

>
>
> 2016-10-28 12:29 GMT+02:00 Thierry Goubier :
>
>>
>>
>> 2016-10-28 11:56 GMT+02:00 Esteban Lorenzano :
>>
>>> VM here: http://bintray.com/estebanlm/pharo-vm/build#files/
>>> Image here: http://files.pharo.org/get-files/60/pharo-64.zip
>>>
>>
>> Thanks.
>>
>>
>>>
>>> this is still not official (that’s why is not in official place) so
>>> there are a couple of known problems:
>>>
>>> - version format is different, and that breaks some things in image that
>>> depends on it to know what happens
>>> - command line is different and probably you’ll need to play a bit with
>>> options (one or two dashes).
>>> - UFFI has some failing tests (but most of it works).
>>>
>>> I would appreciate some help to report and/or fix the emerging problems.
>>>
>>
>> I'll make myself a Makefile for it and test; if I see it stable enough,
>> I'll try to use it on a regular basis and report.
>>
>
> Report:
>
> apart from the missing SSL support which makes loading complex stuff from
> github a bit painfull, it seems to be usable enough.
>
> OSProcess and GitFileTree work fine. Which means gitfiletree:// urls work,
> but not github:// urls.
>
> I loaded a large project (a compiler!) and saw no issues (apart from a
> freetype / wrong glyph issue?). All SmaCC tests are green on it, and my
> project tests were green as well.
>
> Thierry
>
>
>
>>
>> Thierry
>>
>>
>>>
>>> cheers,
>>> Esteban
>>>
>>> On 28 Oct 2016, at 10:39, Thierry Goubier 
>>> wrote:
>>>
>>> Hi all,
>>>
>>> anybody knows how to get (and test) the 64bits version of the Pharo vm
>>> and image?
>>>
>>> Thanks,
>>>
>>> Thierry
>>>
>>>
>>>
>>
>

Re: [Pharo-dev] [Ann] Stack Android VM

[Aliaksei Syrel]

AMAZING!!!

I will definitely try to compile :)
Thanks a lot for this great work! Keep it up!

Cheers,
Alex

On 23 October 2016 at 22:03, Santiago Bragagnolo <
santiagobragagn...@gmail.com> wrote:

>Still far from production. But since i would happy to have some
> feedback, I'm happy to show you some progress on the android VM. Not yet
> release. But we have already a way of compiling and deploying an image into
> an android device.
>
>   You can check it in this repo github.
>   https://github.com/sbragagnolo/pharo-vm/
>
>   The building steps are detailed on the README-Android.md file.
> Building the Stack AndroidVM
>
>1.
>
>Download the sources from github
>
>
>git clone --depth=1 https://github.com/sbragagnolo/pharo-vmcd pharo-vm
>
>2.
>
>Set-up your environment: This script will download the SDK installer
>and NDK R10
>
>cd android/scripts
>./setupAndroidEnvironment.st
>
>This script downloads the content from
>- 'http://dl.google.com/android/repository/android-ndk-r10e-
>   linux-x86_64.zip'.
>   - 'http://dl.google.com/android/android-sdk_r24.4.1-linux.tgz'.
>
>After this process you should have available the environment variables
>ANDROID_NDK_HOME and ANDROID_SDK_HOME. Ensure this by checking your .bashrc
>file at the user's home directory.
>3.
>
>Create a new image: this image will be created by pointing to this
>local git repository
>
>cd android/scripts
>./newImage.st
>
>4.
>
>Link sources to the build folder: The Android vm relies on a Java
>wrapper. This sources must be accessible from the build folder.
>
>cd android/scripts
>./linkSources.st
>
>5.
>
>Generate the sources of the stack vm: This script executes the
>generator of the image created on int the 3rd step.
>
>cd android/scripts
>./generateStackAndroidMake.st
>
>6.
>
>Generate the resource image for deployment: This script download and
>suites up an image for deployment on the folder build/assets/
>SmalltalkRessources
>
>cd android/scripts
>./newResourceImage.st
>
>This image created in this point is downloaded with it related VM for
>editing and loading the code you want to deploy, or configure the things
>you want.
>7.
>
>The VM compilation: This script generates the libraries with the VM
>code.
>
>cd build
>./build.sh
>
>8.
>
>The Java wrapper compilation and Android Application packaging
>
>cd build
>./package.sh
>
>9.
>
>Installing into your device. If you want to generate an APK file with
>your custom name, you will need to deal with the AndroidManifest.xml before
>runing the package.sh script :)
>
>cd build/bin
>adb install -r StackActivity-debug.apk
>
>
>
> - Im currently working on the JIT version of the VM, that still avoiding
> me :).
>  But you have as well the instruction on the same README-Android.me file.
>
>
>  Santiago
>
>
>
>
>
>
>
>

Re: [Pharo-dev] [ANN] Sparta v1.1

[Aliaksei Syrel]

As Doru already mentioned text editor is an important part of the tools.
There are some requirements a text editor should fulfil.


   1. Support of large files ( >> 100mb)
   2. Support of large pieces of text located in memory
   3. Allow developers to embed visual elements (pictures, interactive
   elements, custom elements)
   4. Support of more sophisticated layouts rather than line-based. For
   example columns.
   5. Line breaking
   6. Text wrapping
   7. Hyphens
   8. Should be fast

Tests show that TxText model is very nice for basic cases, works well for
"normal" use.
However, when it comes to extreme cases linked list of spans just fails,
while rope shows great performance - and it also scales.

Cheers,
Alex

On 19 October 2016 at 23:51, Denis Kudriashov <dionisi...@gmail.com> wrote:

>
> 2016-10-19 18:06 GMT+02:00 Aliaksei Syrel <alex.sy...@gmail.com>:
>
>>  - Added initial text support, for instance rendering and high precision
>> measurement.
>
>
> I look at code and it seems you implemented another one new text model?
> Why you not use TxText?
>

Re: [Pharo-dev] [ANN] Sparta v1.1

[Aliaksei Syrel]

I use plugin for months and never had a single random crash :)
It is very stable

On Oct 22, 2016 11:55 AM, "Aliaksei Syrel" <alex.sy...@gmail.com> wrote:

> MozServices crash is intentional!
> When you load Sparta using metacello it runs installer scripts and
> automatically starts services. But they are already running if you have
> Sparta installed.
>
> I need to find a pretty solution for it. Actually it is complicated.
> Services can not just stop while image is running, because rendering would
> instantly crash. Imagine if Bloc is running on Sparta, playground is
> rendered on Sparta. And now you stop services to update. What should
> happen? :)
>
> Just take fresh image. I will add an assertion to forbid Sparta
> installation if it is already installed.
>
> Cheers
> Alex
>
> On Oct 22, 2016 2:09 AM, "Dale Henrichs" <dale.henri...@gemtalksystems.com>
> wrote:
>
>> Right, but since there are known bugs in Sierra perhaps MozServices is
>> hitting one of them.
>>
>> In our case we hit a bug in poll() which is a bit surprising and
>> apparently the bug is hitting Apple's own curl implementation -- see
>> discussion here[1]...
>>
>> Dale
>> [1] https://github.com/curl/curl/issues/1057
>>
>> On 10/21/2016 04:56 PM, Denis Kudriashov wrote:
>>
>> Hi Dale
>>
>> 2016-10-22 1:20 GMT+02:00 Dale Henrichs <dale.henri...@gemtalksystems.com
>> >:
>>
>>> Denis,
>>>
>>> Sierra seems to have some issues. A couple weeks ago one of our users
>>> ran into a problem with Pharo3.0 and Sierra
>>>
>> Pharo works fine. When I first time load Sparta everything works well. I
>> am not saw any problem.
>> But it crashed when MozServices are starting second time where dll call
>> is failed (last log entry)
>>
>>
>>
>>

Re: [Pharo-dev] [ANN] Sparta v1.1

[Aliaksei Syrel]

MozServices crash is intentional!
When you load Sparta using metacello it runs installer scripts and
automatically starts services. But they are already running if you have
Sparta installed.

I need to find a pretty solution for it. Actually it is complicated.
Services can not just stop while image is running, because rendering would
instantly crash. Imagine if Bloc is running on Sparta, playground is
rendered on Sparta. And now you stop services to update. What should
happen? :)

Just take fresh image. I will add an assertion to forbid Sparta
installation if it is already installed.

Cheers
Alex

On Oct 22, 2016 2:09 AM, "Dale Henrichs" 
wrote:

> Right, but since there are known bugs in Sierra perhaps MozServices is
> hitting one of them.
>
> In our case we hit a bug in poll() which is a bit surprising and
> apparently the bug is hitting Apple's own curl implementation -- see
> discussion here[1]...
>
> Dale
> [1] https://github.com/curl/curl/issues/1057
>
> On 10/21/2016 04:56 PM, Denis Kudriashov wrote:
>
> Hi Dale
>
> 2016-10-22 1:20 GMT+02:00 Dale Henrichs 
> :
>
>> Denis,
>>
>> Sierra seems to have some issues. A couple weeks ago one of our users ran
>> into a problem with Pharo3.0 and Sierra
>>
> Pharo works fine. When I first time load Sparta everything works well. I
> am not saw any problem.
> But it crashed when MozServices are starting second time where dll call
> is failed (last log entry)
>
>
>
>

Re: [Pharo-dev] [ANN] Sparta v1.1

[Aliaksei Syrel]

Hi Denis

Thanks for your questions! They are important.
Unfortunately, I didn't have time today to perform a detailed comparison
and stress test of txtext model.
I will answer tomorrow :)

Cheers,
Alex

On 20 October 2016 at 22:17, Denis Kudriashov  wrote:

>
> 2016-10-20 1:15 GMT+02:00 Glenn Cavarlé :
>
>> Good job Alex!
>> Yes, the development version of Bloc is already based on Sparta.
>> The stable version 0.10.1 is the last version with Athens support.
>>
>
> What the repository for Bloc?
>

Re: [Pharo-dev] [ANN] New release of iceberg

[Aliaksei Syrel]

Hi

I use Iceberg to load project in non-interactive mode and this is what I
get with latest stable:

RETRY->BaselineOfIceberg An attempt to use interactive tools detected,
while in non-interactive mode

Is there any reason that prevents Iceberg to be used in non-interactive
mode, from command line for example?

Cheers,
Alex

On 15 October 2016 at 13:59, stepharo  wrote:

> + 1
>
> This is on my todo  :)
>
>
> Le 13/10/16 à 20:37, Tudor Girba a écrit :
>
> Hi Nicolas,
>>
>> Great work!
>>
>> I will test it again. I kindly ask everyone else to follow the call and
>> test this release. Ideally, create a repository on GitHub and play with it.
>>
>> It is important to get this piece as stable as possible to make Git part
>> of the default Pharo experience.
>>
>> Cheers,
>> Doru
>>
>>
>> On Oct 13, 2016, at 2:25 PM, Nicolas Passerini 
>>> wrote:
>>>
>>> Hi, we are releasing a new version of Iceberg, with several new features
>>> and bugfixes. I would't yet say that is 100% production ready, but it is
>>> close, so I want to invite you to test it and provide feedback.
>>>
>>> You can install it by doing:
>>>
>>> Metacello new
>>>baseline: 'Iceberg';
>>>repository: 'github://npasserini/iceberg';
>>>load.
>>>
>>> More installation instructions and documentation can be found at
>>> https://github.com/npasserini/iceberg.
>>>
>>> Some of the new features in this version are:
>>> - Allow to commit several packages together in the same commit.
>>> - Show diffs for incoming and outgoing commits (i.e. before push/pull
>>> you can browse the difference between the remote and the local versions).
>>> - New History view allows to see any commit in any branch and compare it
>>> to the current loaded version.
>>> - Better support for interacting code loaded outside Iceberg
>>> (smaltalkhub, filetree, gitfiletree, etc).
>>> - From the diff view, revert changes or browse them (i.e. open a
>>> Nautilus on the changed class/method).
>>> - Automatically update presentations on code / repository changes.
>>> - Integration with Metacello, i.e. after installing Iceberg you do
>>> something like
>>>
>>> Metacello new
>>>
>>>baseline: 'TaskIt'
>>> ;
>>>repository: 'github://sbragagnolo/taskit'
>>> ;
>>>load.
>>>
>>>
>>> (By default) it will be loaded using iceberg (there is a setting to
>>> avoid it if you prefer traditional behavior.
>>>
>>> - Improved handling of git errors.
>>> - Improved performance for several operations.
>>> - Improved documentation.
>>> - ... and several bug fixes and other minor improvements (please look at
>>> https://github.com/npasserini/iceberg/milestone/7?closed=1 for more
>>> details).
>>>
>>>
>>> Please do not hesitate to contact me if you have any doubts.
>>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "Reasonable is what we are accustomed with."
>>
>>
>>
>>
>
>

Re: [Pharo-dev] [ANN] Sparta v1.0

[Aliaksei Syrel]

Moz2D is used in Firefox to render webpages. For us it means that it
supports all latest web features (concerning graphics) and allows us to
finally implement the whole SVG standard.

> "Why would one use it rather than the
other existing Pharo libraries/wrappers?"

As far as I know there are two 2D libraries in Pharo: BitBlt and Athens
(backend Cairo). Obviously BitBlt does not fit all our needs :) Athens is
nice vector graphics abstraction. However, it does not support shadows,
filters, clipping by arbitrary path, only works in global coordinates and
has primitive text rendering. All those features were not necessary at the
time it was developed. Another problem is statefullness of Athens (state is
shared between draw operation) which does not fit so good when it comes to
the rendering of an element tree. There is a modern trend to move from
statefull to stateless frameworks.

It is almost impossible to extend Athens without breaking user applications
that use it.

So, Sparta is Athens2 that adds support of all mentioned features. It is
inspired and based on amazing work of Igor Stasenko.

In Pharo we have bindings to Cairo. Which is old, lacks on features and no
more maintained so good as it was before. To be performant we need to use
native backends on every platform: D2D1 on Windows, X11 on Linux,
CoreGraphics on Mac. Just imagine how much work is needed to implement
bindings for every mentioned backend :) And do not forget that CoreGraphics
is Object-C and can not be directly called through FFI, it has to be
wrapped in C first...
With Moz2D we get them all out of box for fee :)

Cheers
Alex

On Sep 5, 2016 16:28, "Sean P. DeNigris" <s...@clipperadams.com> wrote:

> Aliaksei Syrel wrote
> > bindings to the Moz2D rendering backend.
>
> Great! What is the use case for Moz2D? Why would one use it rather than the
> other existing Pharo libraries/wrappers?
>
>
>
> -
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/ANN-
> Sparta-v1-0-tp4914154p4914184.html
> Sent from the Pharo Smalltalk Developers mailing list archive at
> Nabble.com.
>
>

Re: [Pharo-dev] [ANN] Sparta v1.0

[Aliaksei Syrel]

>
> How does this handles accelerated graphics?


Nice question :)

There are 3 ways to create a canvas:

1) canvas for offscreen rendering. In this case it must be rasterized in
order to be displayed on the screen. (requres pixel copying)
2) canvas for existing pixel buffer. In this case every draw operation
directly manipulates pixels. For example there is a way to get a pointer to
pixel buffer of SDL Window and create sparta canvas that would wrap it (no
pixel copying required, very fast).
3) canvas for GL context. For example we could create an SDL window with
OpenGL support, get GLContext and create canvas that would operate on it.
(fast but a bit complicated).

First way can result in either software or hardware rendering. For example
on Mac users can choose one of the following backends: CoreGraphics CPU or
CoreGraphics GPU, Skia CPU or Skia GPU and even Cairo.

Second way does not allow to use GPU Accelerated backends, since canvas is
created for pixel buffer. On Mac it is CoreGraphics CPU, Skia CPU or Cairo.

Third way actually allows to create GPU accelerated canvas. For example
Skia GPU renders everything using OpenGL. It is supported on all platforms:
windows, linux, mac, android, iOS.

The most simple way to create a new canvas is:

> canvas := MozCanvas extent: 500@400.


Behind the scenes it chooses the best backend for current platform: D2D1 on
Windows, CoreGraphics on Mac and Skia+X11 mixture on Linux.

Important to mention that Sparta allows developers to manually select which
backend to use.

Cheers,
Alex

On 5 September 2016 at 14:51, philippe.b...@highoctane.be <
philippe.b...@gmail.com> wrote:

> Sweet.
>
> How does this handles accelerated graphics?
>
> Phil
>
> Le 5 sept. 2016 11:52, "Aliaksei Syrel" <alex.sy...@gmail.com> a écrit :
>
>> Hi
>>
>> I am happy to announce the release of Sparta v1.0 for Pharo 5 and Pharo 6.
>> https://github.com/syrel/Sparta/tree/v1.0
>> For a moment only Linux and Mac are supported.
>>
>> It can be bootstrapped with the following script:
>>
>> Metacello new
>>   baseline: 'Sparta';
>>   repository: 'github://syrel/sparta:v1.0/src';
>>   load: #file:core
>>
>>
>> (on linux install 32bit libgtk-2, lingtk-3 and libstdc++)
>> (script for ubuntu http://ws.stfx.eu/IEAWCUC18BH)
>>
>> Sparta is an almost stateless vector graphics API for Pharo that provides
>> bindings to the Moz2D rendering backend. Moz2D is the extracted graphical
>> engine from Mozilla Firefox compiled as standalone shared library together
>> with the extern C bindings required to call the engine from Pharo.
>>
>> - developed with the help of Iceberg
>> <https://github.com/npasserini/iceberg> (thanks!) on Github.
>> - integrated into travis-ci <https://travis-ci.org/syrel/Sparta> using
>> smalltalkCI <https://github.com/hpi-swa/smalltalkCI> (great job!).
>> - documented using Pillar <https://github.com/pillar-markup/pillar> (so
>> better!) syntax.
>>
>> Cheers,
>> Alex
>>
>

[Pharo-dev] [ANN] Sparta v1.0

[Aliaksei Syrel]

Hi

I am happy to announce the release of Sparta v1.0 for Pharo 5 and Pharo 6.
https://github.com/syrel/Sparta/tree/v1.0
For a moment only Linux and Mac are supported.

It can be bootstrapped with the following script:

Metacello new
  baseline: 'Sparta';
  repository: 'github://syrel/sparta:v1.0/src';
  load: #file:core


(on linux install 32bit libgtk-2, lingtk-3 and libstdc++)
(script for ubuntu http://ws.stfx.eu/IEAWCUC18BH)

Sparta is an almost stateless vector graphics API for Pharo that provides
bindings to the Moz2D rendering backend. Moz2D is the extracted graphical
engine from Mozilla Firefox compiled as standalone shared library together
with the extern C bindings required to call the engine from Pharo.

- developed with the help of Iceberg
 (thanks!)
on Github.
- integrated into travis-ci  using
smalltalkCI  (great job!).
- documented using Pillar  (so
better!) syntax.

Cheers,
Alex

Re: [Pharo-dev] Layout in bloc

[Aliaksei Syrel]

Hi

Thanks for the example. Exactly, ability to have elements that are visible
but not participate in layout is very important. But first I would like to
describe bloc layout a bit more.

-
If you think for a second about the meaning of "layout" you would realize
that layout is just "the way in which the parts of something are arranged
or laid out". So, actually, layout is all about determining the positions
of elements within the parent (origin of bounds). However, real world is a
bit more complicated, especially when it comes to visual elements. In our
world we must also compute size (extent) of every element before actually
laying it out. Bad news is that size depends on layout type and layout
constraints (match parent, fit content, take exact size) that may depend
rather on children or parent.

In Bloc the whole process is divided in two parts: measurement and layout.
They are completely separated and do not overlap.

During measurement step we iterate over the whole tree and depending on
layout and constraints only compute extent of every element. For
optimisation purposes layout caches previous extent and if during new
measurement step it does not change, we stop, skipping children. There is a
rule: if child's constraints didn't change and if child's measurement bit
is not dirty and if parent's extent is the same child will have the same
extent.

Than comes layout step. Because we already measured all extents we can
easily determine positions within the parent, and logic is very simple.
-

Now let's think about visibility and visible: setter. What argument should
it be? How do we encode visibility. In Morphic it is a Boolean. However, in
real world it is a bit more complicated.

Sometimes we want an element to be completely gone, it is not visible and
does not take any space within the parent and does not participate in
layout.
Sometimes we want an element to be hidden, it is not visible but it still
occupies space within the parent (it is just empty) and do participate in
layout.
Sometimes we want an element to be floating, it is visible but does not
occupy any space and does not participate in layout. However, a floating
element must be measured (extent computed), we just do not want to compute
its position and simply let user set it manually.

To conclude, instead of Boolean in Bloc visibility is defined
by BlVisibility object.


Floating mode is exactly what you want, Alex. It can be set easily:

> txt constraints beFloating.


However, I just checked and it does not work. Looks like this feature was
removed during last iteration. I find this feature is a huge step forward,
but now we are many steps back :(


Cheers,
Alex

On 28 August 2016 at 02:24, Alexandre Bergel 
wrote:

> Hi!
>
> I am working on a popup support in Bloc and I am facing a problem.
> Consider the following code:
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> space := BlSpace new.
> space root layout: BlLinearLayout horizontal.
> 10
> timesRepeat: [ | e |
> e := (BlRectangle new extent: 20 @ 20) asElement.
> e background: Color random.
> space root addChild: e ].
> space root children withIndexDo: [ :e :index | e translateBy:
> (index * 30) @ 10 ].
>
> space root children do: [ :e |
> e
> addEventHandler:
> (BlEventHandler
> on: BlMouseEnterEvent
> do: [ :evt |
> | txt |
> txt := BlText new
> position: evt
> position;
> fill: Color red;
> text: 'Hello
> World'.
>
> e parent addChild: txt ]).
>
>  ].
> space show
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> If you uncomment the second line (“space root layout:…”), then the string
> hello world is added text to the element in which the mouse enter. With the
> layout, the string is added at the end of the line.
>
> I like very much the idea of having the layout applied when elements are
> added (even I suspect we may have scalability issues very soon), but in
> that situation, this is not wished.
>
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

Re: [Pharo-dev] Athens Font Rendering Bug

[Aliaksei Syrel]

Hi

Actually it is not Athens bug. Problem is in string extent measurement done
by text morph. Athens (Cairo in the end) only renders string glyphs created
by FreeType2 on positions specified by someone else (morphic in this case).

Cheers
Alex
On Jul 10, 2016 6:16 PM, "J.F. Rick"  wrote:

> Perhaps other people have already reported this for Bloc but something is
> wrong with the font rendering of Athens. Here's the code and how it is
> rendered in Athens vs how it is rendered in BitBlt. It seems like Athens
> adds more space between letters than is supposed to be there.
>
> tMorph := TextMorph new.
> font1 := TextFontReference toFont: (LogicalFont familyName: 'Arial'
> fallbackFamilyNames: nil pointSize: 28 stretchValue: 5 weightValue: 400
> slantValue: 0).
> font2 := (TextFontReference toFont: (StrikeFont familyName: 'Atlanta'
> size: 11)).
> t1 := 'this is font1' asText addAttribute: font1.
> t2 := ' and this is font2' asText addAttribute: font2.
> tMorph contents: (t1,t2).
>
> Cheers,
>
> Jeff
>