Re: [Pharo-dev] , for vector creation

[Nicolai Hess]

Am 25.10.2017 10:50 PM schrieb "Torsten Bergmann" :

Hi,

there might be reasons for an own 2D vector class (instead of using Point).
But still I dislike the reimplementation of  "," because for me so far it
has the meaning of "concatenating things".



Like concatenating coordinates :-)



Here you redefine it to create vector instances and it works only up to
three
so far. Right?

I understand that this gives some similarities with the math notation (1,2)
but I personally would prefer to use:

1@2 asVector

or  Vector2D x: 1 y: 2

Thx
T.



> Gesendet: Mittwoch, 25. Oktober 2017 um 20:06 Uhr
> Von: "Tudor Girba" 
> An: "Pharo Development List" 
> Betreff: [Pharo-dev] , for vector creation
>
> Hi,
>
> As mentioned in the separate thread, we played with introducing the
extension:
>
> , aNumber
>   ^ BlVector2D x: self y: aNumber
>
> This means that (10,20) will return a 2D vector.
>
> We also have (10,20,30) which returns a 3D vector.
>
> , is used for different meanings already in the image beside the
collection concatenation. For example, in FileReference is adds a file
extension. And Exceptions create a collection. In other packages,
PetitParser uses it as a sequence operator.
>
> Please voice your concerns.
>
> Cheers,
> Doru
>
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Every thing should have the right to be different."
>
>
>
>
>
>

Re: [Pharo-dev] , for vector creation

[henry]

I would note that 1 ! 2 creates/extends an ETuple in eLinda.

- HH

On Wed, Oct 25, 2017 at 16:53, Stephane Ducasse  wrote:

> In Polymath I guess that the vectors are longer. But if I'm correct it is #( 
> 12 23) asVector. Doru did you look at Jun because Jun introduced 3DPoint and 
> I wonder if they did not introduce Vector? What would be the alternatives for 
> vector? Any idea how this is done in other languages 1~>2 1!2 1-}2 Stef On 
> Wed, Oct 25, 2017 at 8:56 PM, Tudor Girba wrote: > Hi, > > Vector is not 
> Bloc-sepcific. We just need it in Bloc and because there wasn’t any, we now 
> have one in Bloc. But, it can be pulled out without any issues. > > Cheers, > 
> Doru > > >> On Oct 25, 2017, at 8:21 PM, Peter Uhnák wrote: >> >> For 
> example, in FileReference is adds a file extension. PetitParser uses it as a 
> sequence operator. >> >> But in both cases #, is sent to FileReference/Petit 
> parser instance, so it is contained. >> You would use it on a (generic) 
> Number and tie it to specific Bloc meaning. Maybe have a polymorphic Vector 
> in regular Pharo (I would imagine that PolyMath could also make use of that)? 
> >> >> Peter > > -- > www.tudorgirba.com > www.feenk.com > > "Obvious things 
> are difficult to teach." > > > > > @gmail.com> @tudorgirba.com>

Re: [Pharo-dev] feenk log

[Sean P. DeNigris]

Tudor Girba-2 wrote
> We now have BlScalableElement which handles the zooming

Gotcha. So an entire "World" (I'm assuming that's a Bloc Space?) can be
zoomed in and out?



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] , for vector creation

[Denis Kudriashov]

2017-10-25 22:53 GMT+02:00 Stephane Ducasse :

> In Polymath I guess that the vectors are longer. But if I'm correct it
> is #( 12 23) asVector.
>

And I am wondering, Polymath already implements linear algebra. Right? Can
we just use it in Bloc?


>
> Doru did you look at Jun because Jun introduced 3DPoint and I wonder
> if they did not introduce Vector?
>
> What would be the alternatives for vector?
> Any idea how this is done in other languages
>
> 1~>2
> 1!2
> 1-}2
>
> Stef
>
>
> On Wed, Oct 25, 2017 at 8:56 PM, Tudor Girba  wrote:
> > Hi,
> >
> > Vector is not Bloc-sepcific. We just need it in Bloc and because there
> wasn’t any, we now have one in Bloc. But, it can be pulled out without any
> issues.
> >
> > Cheers,
> > Doru
> >
> >
> >> On Oct 25, 2017, at 8:21 PM, Peter Uhnák  wrote:
> >>
> >> For example, in FileReference is adds a file extension. PetitParser
> uses it as a sequence operator.
> >>
> >> But in both cases #, is sent to FileReference/Petit parser instance, so
> it is contained.
> >> You would use it on a (generic) Number and tie it to specific Bloc
> meaning. Maybe have a polymorphic Vector in regular Pharo (I would imagine
> that PolyMath could also make use of that)?
> >>
> >> Peter
> >
> > --
> > www.tudorgirba.com
> > www.feenk.com
> >
> > "Obvious things are difficult to teach."
> >
> >
> >
> >
> >
>
>

Re: [Pharo-dev] feenk log

[Stephane Ducasse]

On Wed, Oct 25, 2017 at 7:04 PM, Aliaksei Syrel  wrote:
> 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 :)

Yes for the extras problems but you always have an idea of the base.

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

I was wondering if the use of on:fork: would not help there.

> 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)
Ok you mean what glenn did. Ok sounds good. For me I would like to
have less concepts or similar libraries.

>  - 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 :)

Ok so this is reasonable.
I would add for version 1.0
Nice class comments


> Cheers,
> Alex
>
> On 25 October 2017 at 18:48, Aliaksei Syrel  wrote:
>>
>> Hi Denis,
>>
>> The reason for BlVector2D is that we also have BlVector3D.
>> 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

[Stephane Ducasse]

Ok :)

Stef

On Wed, Oct 25, 2017 at 7:58 PM, Tudor Girba  wrote:
> Hi Stef,
>
> The log is not a replacement of the roadmap. It is only to help people see 
> what we do live.
>
> The roadmap and documentation are coming as well, but these are separate.
>
> Cheers,
> Doru
>
>
>> On Oct 25, 2017, at 6:45 PM, Stephane Ducasse  
>> wrote:
>>
>> Doru having a few tweets is nice but I do not think that you
>> communicate well around bloc.
>>
>> What I would like to get is a roadmap for Bloc V1.0.
>> - Here are the missing features (documentation),
>> - Here are where we are.
>> Because else it feels like Bloc will never ends.
>> You will argue and tell me that you experiments. But without a feature
>> list then
>> people cannot join and do not know when you get a 1.0.
>>
>> Not measuring is the best way to arrive to a point where you did not wanted.
>>
>> You see for Brick we need
>>Button
>>CheckBox
>>DropList
>>List
>>Table
>>Pane
>>InputField
>>Text
>>Scrollbar
>>Menu
>> And with that we can get a first Widget set.
>> But again without a roadmap I have some doubts.
>>
>> Stef
>>
>>
>> Stef
>>
>>
>> On Wed, Oct 25, 2017 at 6:38 PM, Stephane Ducasse
>>  wrote:
>>> Doru using comma for creating vectors is not really because it will
>>> just make the life of type inferencers more difficult.
>>>
>>>
>>> On Wed, Oct 25, 2017 at 5:53 PM, Tudor Girba  wrote:
 Hi,

 Our team is working on a couple of projects that are relevant for the core 
 of Pharo, namely GT and Bloc/Brick. At ESUG we were asked by several 
 people, and Stef in particular, to make the progress on these projects 
 more transparent. To this end, we will start two streams of signals:
 - fine grained info bits on out Twitter account (several times a week): 
 https://twitter.com/feenkcom
 - a less often but regular (probably every 2 weeks) activity log message 
 sent to this mailing list

 Please let us know if you see an issue with this.

 In the meantime, let’s start.

 Bloc:
 - Over the past couple of weeks Alex worked on transformations and 
 measurements in the core system. It turns out that there was room for 
 quite a number of performance optimizations and for making the system more 
 debuggable.
 - At the low level, this involved adding matrix and vector support.
 https://twitter.com/feenkcom/status/923123870537863168
 https://twitter.com/feenkcom/status/916300180848349185
 - At a higher level, it implies keeping track of measurements
 https://twitter.com/AliakseiSyrel/status/915203525931622400
 - And of transformations:
 https://twitter.com/feenkcom/status/919603739656417281
 https://twitter.com/feenkcom/status/917116164484096001
 - The BlScalableElement is now working properly

 GT Examples:
 - The current repository with unary-based examples is at: 
 https://github.com/feenkcom/gtoolkit-examples
 - We now have a runner in the inspector that allows us to both see the 
 source code and run and play with the resulting object:
 https://twitter.com/feenkcom/status/923210686204989442
 - Andrei made the “after” behavior to work with unary examples.

 Cheers,
 The feenk team

 --
 www.tudorgirba.com
 www.feenk.com

 "Being happy is a matter of choice."





>>
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "What we can governs what we wish."
>
>
>
>
>

Re: [Pharo-dev] , for vector creation

[Stephane Ducasse]

In Polymath I guess that the vectors are longer. But if I'm correct it
is #( 12 23) asVector.

Doru did you look at Jun because Jun introduced 3DPoint and I wonder
if they did not introduce Vector?

What would be the alternatives for vector?
Any idea how this is done in other languages

1~>2
1!2
1-}2

Stef


On Wed, Oct 25, 2017 at 8:56 PM, Tudor Girba  wrote:
> Hi,
>
> Vector is not Bloc-sepcific. We just need it in Bloc and because there wasn’t 
> any, we now have one in Bloc. But, it can be pulled out without any issues.
>
> Cheers,
> Doru
>
>
>> On Oct 25, 2017, at 8:21 PM, Peter Uhnák  wrote:
>>
>> For example, in FileReference is adds a file extension. PetitParser uses it 
>> as a sequence operator.
>>
>> But in both cases #, is sent to FileReference/Petit parser instance, so it 
>> is contained.
>> You would use it on a (generic) Number and tie it to specific Bloc meaning. 
>> Maybe have a polymorphic Vector in regular Pharo (I would imagine that 
>> PolyMath could also make use of that)?
>>
>> Peter
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Obvious things are difficult to teach."
>
>
>
>
>

[Pharo-dev] , for vector creation

[Torsten Bergmann]

Hi,

there might be reasons for an own 2D vector class (instead of using Point).
But still I dislike the reimplementation of  "," because for me so far it 
has the meaning of "concatenating things".

Here you redefine it to create vector instances and it works only up to three
so far. Right?

I understand that this gives some similarities with the math notation (1,2)
but I personally would prefer to use:

1@2 asVector

or  Vector2D x: 1 y: 2 

Thx
T.



> Gesendet: Mittwoch, 25. Oktober 2017 um 20:06 Uhr
> Von: "Tudor Girba" 
> An: "Pharo Development List" 
> Betreff: [Pharo-dev] , for vector creation
>
> Hi,
> 
> As mentioned in the separate thread, we played with introducing the extension:
> 
> , aNumber
>   ^ BlVector2D x: self y: aNumber
> 
> This means that (10,20) will return a 2D vector.
> 
> We also have (10,20,30) which returns a 3D vector.
> 
> , is used for different meanings already in the image beside the collection 
> concatenation. For example, in FileReference is adds a file extension. And 
> Exceptions create a collection. In other packages, PetitParser uses it as a 
> sequence operator.
> 
> Please voice your concerns.
> 
> Cheers,
> Doru
> 
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "Every thing should have the right to be different."
> 
> 
> 
> 
> 
> 

Re: [Pharo-dev] feenk log

[Denis Kudriashov]

2017-10-25 22:00 GMT+02:00 Tudor Girba :

> Hi,
>
> > On Oct 25, 2017, at 8:11 PM, Sean P. DeNigris 
> wrote:
> >
> > Denis Kudriashov wrote
> >> Good initiative.
> >
> > +1 :)
> >
> >
> > Denis Kudriashov wrote
> >> Here is my twitter questions:…
> >
> > Mine are:
> > 1. Is it possible/easy/smooth to zoom in/out?
>
> We now have BlScalableElement which handles the zooming. The next thing is
> to attach animations to it.
>

I expected that any element can be scalable because transformation is part
of it. Am I wrong?.
Then what the purpose of this subclass? Is it for convenience or there is
some important logic inside?


>
> > 2. Is there an equivalent to Morphic-stepping?
>
> Yes, but this is achieved by attaching an animation to the element.
>
> However, right now, due to changes in transformations, animations are not
> working. They should be back soon.
>
> Cheers,
> Doru
>
> >
> >
> > -
> > Cheers,
> > Sean
> > --
> > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.
> html
> >
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Reasonable is what we are accustomed with."
>
>
>

Re: [Pharo-dev] feenk log

[Tudor Girba]

Hi,

> On Oct 25, 2017, at 8:11 PM, Sean P. DeNigris  wrote:
> 
> Denis Kudriashov wrote
>> Good initiative.
> 
> +1 :)
> 
> 
> Denis Kudriashov wrote
>> Here is my twitter questions:…
> 
> Mine are:
> 1. Is it possible/easy/smooth to zoom in/out?

We now have BlScalableElement which handles the zooming. The next thing is to 
attach animations to it.

> 2. Is there an equivalent to Morphic-stepping?

Yes, but this is achieved by attaching an animation to the element.

However, right now, due to changes in transformations, animations are not 
working. They should be back soon.

Cheers,
Doru

> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
> 

--
www.tudorgirba.com
www.feenk.com

"Reasonable is what we are accustomed with."

Re: [Pharo-dev] UnifiedFFI Docs

[Todd Blanchard]

OK, new question.

How do I file this in?  I was able to load tonel from iceberg.  I added the 
repo and it gave me a choice of packages to load and I loaded them using the 
iceberg browser.

I added this to the iceberg browser and there are no packages listed and I have 
absolutely no clue how to get this code into my image.

I'm about 80 hours into trying to get my head around FFI and really getting 
discouraged at how many walls I'm hitting trying to get a foreign library 
interface done.

> On Oct 25, 2017, at 7:35 AM, Esteban Lorenzano  wrote:
> 
> :)
> 
> Did you look at this project: 
> https://github.com/estebanlm/libclang-pharo-bindings/ 
>  ?
> 
> it was using parseTranslationUnit (no 2)… there you can find how is being 
> used (I just converted it to tonel format, but older versions are in filetree)
> 
> Esteban
> 
>> On 24 Oct 2017, at 19:17, Todd Blanchard > > wrote:
>> 
>> Hey Esteban,
>> 
>> Now that you have outed yourself as a maintainer of FFI, I have a question. 
>> :-)
>> 
>> I want to call the libclang function:
>> 
>> /**
>> * \brief Parse the given source file and the translation unit corresponding
>> * to that file.
>> *
>> * This routine is the main entry point for the Clang C API, providing the
>> * ability to parse a source file into a translation unit that can then be
>> * queried by other functions in the API. This routine accepts a set of
>> * command-line arguments so that the compilation can be configured in the 
>> same
>> * way that the compiler is configured on the command line.
>> *
>> * \param CIdx The index object with which the translation unit will be 
>> * associated.
>> *
>> * \param source_filename The name of the source file to load, or NULL if the
>> * source file is included in \c command_line_args.
>> *
>> * \param command_line_args The command-line arguments that would be
>> * passed to the \c clang executable if it were being invoked out-of-process.
>> * These command-line options will be parsed and will affect how the 
>> translation
>> * unit is parsed. Note that the following options are ignored: '-c', 
>> * '-emit-ast', '-fsyntax-only' (which is the default), and '-o \> file>'.
>> *
>> * \param num_command_line_args The number of command-line arguments in
>> * \c command_line_args.
>> *
>> * \param unsaved_files the files that have not yet been saved to disk
>> * but may be required for parsing, including the contents of
>> * those files.  The contents and name of these files (as specified by
>> * CXUnsavedFile) are copied when necessary, so the client only needs to
>> * guarantee their validity until the call to this function returns.
>> *
>> * \param num_unsaved_files the number of unsaved file entries in \p
>> * unsaved_files.
>> *
>> * \param options A bitmask of options that affects how the translation unit
>> * is managed but not its compilation. This should be a bitwise OR of the
>> * CXTranslationUnit_XXX flags.
>> *
>> * \param[out] out_TU A non-NULL pointer to store the created
>> * \c CXTranslationUnit, describing the parsed code and containing any
>> * diagnostics produced by the compiler.
>> *
>> * \returns Zero on success, otherwise returns an error code.
>> */
>> enum CXErrorCode
>> clang_parseTranslationUnit2(CXIndex CIdx,
>>const char *source_filename,
>>const char *const *command_line_args,
>>int num_command_line_args,
>>struct CXUnsavedFile *unsaved_files,
>>unsigned num_unsaved_files,
>>unsigned options,
>>CXTranslationUnit *out_TU);
>> 
>> The parts I'm not clear on are turning an array or ordered collection of 
>> strings into an argv/argc, turning an array of CXUnsavedFile's 
>> (FFIExternalStruct) into an array of pointers and count, and getting data 
>> back in an output argument as CXTranslationUnit which is an opaque pointer 
>> to a C++ object.
>> 
>> Any tips on these mappings would be great.  I've currently guessed it as:
>> 
>> clang_parseTranslationUnit__cxIndex: cxIndex source: sourceFile arguments: 
>> argv unsavedFiles:unsaved options: opts
>> 
>>  | argc unsaved_files num_unsaved_files options error out_TU |
>>  argc := argv size.
>>  unsaved_files := unsaved ifNil: [ #() ] ifNotNil: [ unsaved ]. 
>>  num_unsaved_files := unsaved_files ifNil: [ 0 ] ifNotNil: 
>> [unsaved_files size].
>>  options := opts sum.
>>  
>>  error := self ffiCall:  #(CXErrorCode 
>> clang_parseTranslationUnit2(CXIndex cxIndex,
>>   String sourceFile,
>>   String *argv,
>>   uint argc,
>>   CXUnsavedFile *unsaved_files,
>>   uint num_unsaved_files,
>>   

Re: [Pharo-dev] , for vector creation

[Tudor Girba]

Hi,

Vector is not Bloc-sepcific. We just need it in Bloc and because there wasn’t 
any, we now have one in Bloc. But, it can be pulled out without any issues.

Cheers,
Doru


> On Oct 25, 2017, at 8:21 PM, Peter Uhnák  wrote:
> 
> For example, in FileReference is adds a file extension. PetitParser uses it 
> as a sequence operator.
> 
> But in both cases #, is sent to FileReference/Petit parser instance, so it is 
> contained.
> You would use it on a (generic) Number and tie it to specific Bloc meaning. 
> Maybe have a polymorphic Vector in regular Pharo (I would imagine that 
> PolyMath could also make use of that)?
> 
> Peter

--
www.tudorgirba.com
www.feenk.com

"Obvious things are difficult to teach."

Re: [Pharo-dev] , for vector creation

[Peter Uhnák]

>
> For example, in FileReference is adds a file extension. PetitParser uses
> it as a sequence operator.
>

But in both cases #, is sent to FileReference/Petit parser instance, so it
is contained.
You would use it on a (generic) Number and tie it to specific Bloc meaning.
Maybe have a polymorphic Vector in regular Pharo (I would imagine that
PolyMath could also make use of that)?

Peter

Re: [Pharo-dev] feenk log

[Sean P. DeNigris]

Denis Kudriashov wrote
> Good initiative.

+1 :)


Denis Kudriashov wrote
> Here is my twitter questions:…

Mine are:
1. Is it possible/easy/smooth to zoom in/out?
2. Is there an equivalent to Morphic-stepping?



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

[Pharo-dev] , for vector creation

[Tudor Girba]

Hi,

As mentioned in the separate thread, we played with introducing the extension:

, aNumber
^ BlVector2D x: self y: aNumber

This means that (10,20) will return a 2D vector.

We also have (10,20,30) which returns a 3D vector.

, is used for different meanings already in the image beside the collection 
concatenation. For example, in FileReference is adds a file extension. And 
Exceptions create a collection. In other packages, PetitParser uses it as a 
sequence operator.

Please voice your concerns.

Cheers,
Doru


--
www.tudorgirba.com
www.feenk.com

"Every thing should have the right to be different."

Re: [Pharo-dev] feenk log

[Tudor Girba]

Hi,

That is the point of making fine grained things explicit: to have the chance to 
disagree and discuss :).

I will spawn a separate thread.

Doru


> On Oct 25, 2017, at 7:42 PM, Alexandre Bergel  wrote:
> 
>> Personally (10, 20) for a vector is not really nice and I would really
>> like to have a discussion before.
> 
> +1 
> 
> The Pharo syntax should remain an asset, not become a trap.
> 
> Alexandre
> 
>> 
>> 
>> On Wed, Oct 25, 2017 at 6:45 PM, Stephane Ducasse
>>  wrote:
>>> Doru having a few tweets is nice but I do not think that you
>>> communicate well around bloc.
>>> 
>>> What I would like to get is a roadmap for Bloc V1.0.
>>> - Here are the missing features (documentation),
>>> - Here are where we are.
>>> Because else it feels like Bloc will never ends.
>>> You will argue and tell me that you experiments. But without a feature
>>> list then
>>> people cannot join and do not know when you get a 1.0.
>>> 
>>> Not measuring is the best way to arrive to a point where you did not wanted.
>>> 
>>> You see for Brick we need
>>>   Button
>>>   CheckBox
>>>   DropList
>>>   List
>>>   Table
>>>   Pane
>>>   InputField
>>>   Text
>>>   Scrollbar
>>>   Menu
>>> And with that we can get a first Widget set.
>>> But again without a roadmap I have some doubts.
>>> 
>>> Stef
>>> 
>>> 
>>> Stef
>>> 
>>> 
>>> On Wed, Oct 25, 2017 at 6:38 PM, Stephane Ducasse
>>>  wrote:
 Doru using comma for creating vectors is not really because it will
 just make the life of type inferencers more difficult.
 
 
 On Wed, Oct 25, 2017 at 5:53 PM, Tudor Girba  wrote:
> Hi,
> 
> Our team is working on a couple of projects that are relevant for the 
> core of Pharo, namely GT and Bloc/Brick. At ESUG we were asked by several 
> people, and Stef in particular, to make the progress on these projects 
> more transparent. To this end, we will start two streams of signals:
> - fine grained info bits on out Twitter account (several times a week): 
> https://twitter.com/feenkcom
> - a less often but regular (probably every 2 weeks) activity log message 
> sent to this mailing list
> 
> Please let us know if you see an issue with this.
> 
> In the meantime, let’s start.
> 
> Bloc:
> - Over the past couple of weeks Alex worked on transformations and 
> measurements in the core system. It turns out that there was room for 
> quite a number of performance optimizations and for making the system 
> more debuggable.
> - At the low level, this involved adding matrix and vector support.
> https://twitter.com/feenkcom/status/923123870537863168
> https://twitter.com/feenkcom/status/916300180848349185
> - At a higher level, it implies keeping track of measurements
> https://twitter.com/AliakseiSyrel/status/915203525931622400
> - And of transformations:
> https://twitter.com/feenkcom/status/919603739656417281
> https://twitter.com/feenkcom/status/917116164484096001
> - The BlScalableElement is now working properly
> 
> GT Examples:
> - The current repository with unary-based examples is at: 
> https://github.com/feenkcom/gtoolkit-examples
> - We now have a runner in the inspector that allows us to both see the 
> source code and run and play with the resulting object:
> https://twitter.com/feenkcom/status/923210686204989442
> - Andrei made the “after” behavior to work with unary examples.
> 
> Cheers,
> The feenk team
> 
> --
> www.tudorgirba.com
> www.feenk.com
> 
> "Being happy is a matter of choice."
> 
> 
> 
> 
> 
>> 
> 
> 

--
www.tudorgirba.com
www.feenk.com

"Don't give to get. Just give."

Re: [Pharo-dev] feenk log

[Tudor Girba]

Hi Stef,

The log is not a replacement of the roadmap. It is only to help people see what 
we do live.

The roadmap and documentation are coming as well, but these are separate.

Cheers,
Doru


> On Oct 25, 2017, at 6:45 PM, Stephane Ducasse  wrote:
> 
> Doru having a few tweets is nice but I do not think that you
> communicate well around bloc.
> 
> What I would like to get is a roadmap for Bloc V1.0.
> - Here are the missing features (documentation),
> - Here are where we are.
> Because else it feels like Bloc will never ends.
> You will argue and tell me that you experiments. But without a feature
> list then
> people cannot join and do not know when you get a 1.0.
> 
> Not measuring is the best way to arrive to a point where you did not wanted.
> 
> You see for Brick we need
>Button
>CheckBox
>DropList
>List
>Table
>Pane
>InputField
>Text
>Scrollbar
>Menu
> And with that we can get a first Widget set.
> But again without a roadmap I have some doubts.
> 
> Stef
> 
> 
> Stef
> 
> 
> On Wed, Oct 25, 2017 at 6:38 PM, Stephane Ducasse
>  wrote:
>> Doru using comma for creating vectors is not really because it will
>> just make the life of type inferencers more difficult.
>> 
>> 
>> On Wed, Oct 25, 2017 at 5:53 PM, Tudor Girba  wrote:
>>> Hi,
>>> 
>>> Our team is working on a couple of projects that are relevant for the core 
>>> of Pharo, namely GT and Bloc/Brick. At ESUG we were asked by several 
>>> people, and Stef in particular, to make the progress on these projects more 
>>> transparent. To this end, we will start two streams of signals:
>>> - fine grained info bits on out Twitter account (several times a week): 
>>> https://twitter.com/feenkcom
>>> - a less often but regular (probably every 2 weeks) activity log message 
>>> sent to this mailing list
>>> 
>>> Please let us know if you see an issue with this.
>>> 
>>> In the meantime, let’s start.
>>> 
>>> Bloc:
>>> - Over the past couple of weeks Alex worked on transformations and 
>>> measurements in the core system. It turns out that there was room for quite 
>>> a number of performance optimizations and for making the system more 
>>> debuggable.
>>> - At the low level, this involved adding matrix and vector support.
>>> https://twitter.com/feenkcom/status/923123870537863168
>>> https://twitter.com/feenkcom/status/916300180848349185
>>> - At a higher level, it implies keeping track of measurements
>>> https://twitter.com/AliakseiSyrel/status/915203525931622400
>>> - And of transformations:
>>> https://twitter.com/feenkcom/status/919603739656417281
>>> https://twitter.com/feenkcom/status/917116164484096001
>>> - The BlScalableElement is now working properly
>>> 
>>> GT Examples:
>>> - The current repository with unary-based examples is at: 
>>> https://github.com/feenkcom/gtoolkit-examples
>>> - We now have a runner in the inspector that allows us to both see the 
>>> source code and run and play with the resulting object:
>>> https://twitter.com/feenkcom/status/923210686204989442
>>> - Andrei made the “after” behavior to work with unary examples.
>>> 
>>> Cheers,
>>> The feenk team
>>> 
>>> --
>>> www.tudorgirba.com
>>> www.feenk.com
>>> 
>>> "Being happy is a matter of choice."
>>> 
>>> 
>>> 
>>> 
>>> 
> 

--
www.tudorgirba.com
www.feenk.com

"What we can governs what we wish."

Re: [Pharo-dev] UnifiedFFI Docs

[Todd Blanchard]

I did not - had no idea it existed.

Is if fair to say that the 32 bit warning in the readme does not apply to Pharo 
64 bit?  

> On Oct 25, 2017, at 7:35 AM, Esteban Lorenzano  wrote:
> 
> :)
> 
> Did you look at this project: 
> https://github.com/estebanlm/libclang-pharo-bindings/ 
>  ?
> 
> it was using parseTranslationUnit (no 2)… there you can find how is being 
> used (I just converted it to tonel format, but older versions are in filetree)
> 
> Esteban
> 
>> On 24 Oct 2017, at 19:17, Todd Blanchard > > wrote:
>> 
>> Hey Esteban,
>> 
>> Now that you have outed yourself as a maintainer of FFI, I have a question. 
>> :-)
>> 
>> I want to call the libclang function:
>> 
>> /**
>> * \brief Parse the given source file and the translation unit corresponding
>> * to that file.
>> *
>> * This routine is the main entry point for the Clang C API, providing the
>> * ability to parse a source file into a translation unit that can then be
>> * queried by other functions in the API. This routine accepts a set of
>> * command-line arguments so that the compilation can be configured in the 
>> same
>> * way that the compiler is configured on the command line.
>> *
>> * \param CIdx The index object with which the translation unit will be 
>> * associated.
>> *
>> * \param source_filename The name of the source file to load, or NULL if the
>> * source file is included in \c command_line_args.
>> *
>> * \param command_line_args The command-line arguments that would be
>> * passed to the \c clang executable if it were being invoked out-of-process.
>> * These command-line options will be parsed and will affect how the 
>> translation
>> * unit is parsed. Note that the following options are ignored: '-c', 
>> * '-emit-ast', '-fsyntax-only' (which is the default), and '-o \> file>'.
>> *
>> * \param num_command_line_args The number of command-line arguments in
>> * \c command_line_args.
>> *
>> * \param unsaved_files the files that have not yet been saved to disk
>> * but may be required for parsing, including the contents of
>> * those files.  The contents and name of these files (as specified by
>> * CXUnsavedFile) are copied when necessary, so the client only needs to
>> * guarantee their validity until the call to this function returns.
>> *
>> * \param num_unsaved_files the number of unsaved file entries in \p
>> * unsaved_files.
>> *
>> * \param options A bitmask of options that affects how the translation unit
>> * is managed but not its compilation. This should be a bitwise OR of the
>> * CXTranslationUnit_XXX flags.
>> *
>> * \param[out] out_TU A non-NULL pointer to store the created
>> * \c CXTranslationUnit, describing the parsed code and containing any
>> * diagnostics produced by the compiler.
>> *
>> * \returns Zero on success, otherwise returns an error code.
>> */
>> enum CXErrorCode
>> clang_parseTranslationUnit2(CXIndex CIdx,
>>const char *source_filename,
>>const char *const *command_line_args,
>>int num_command_line_args,
>>struct CXUnsavedFile *unsaved_files,
>>unsigned num_unsaved_files,
>>unsigned options,
>>CXTranslationUnit *out_TU);
>> 
>> The parts I'm not clear on are turning an array or ordered collection of 
>> strings into an argv/argc, turning an array of CXUnsavedFile's 
>> (FFIExternalStruct) into an array of pointers and count, and getting data 
>> back in an output argument as CXTranslationUnit which is an opaque pointer 
>> to a C++ object.
>> 
>> Any tips on these mappings would be great.  I've currently guessed it as:
>> 
>> clang_parseTranslationUnit__cxIndex: cxIndex source: sourceFile arguments: 
>> argv unsavedFiles:unsaved options: opts
>> 
>>  | argc unsaved_files num_unsaved_files options error out_TU |
>>  argc := argv size.
>>  unsaved_files := unsaved ifNil: [ #() ] ifNotNil: [ unsaved ]. 
>>  num_unsaved_files := unsaved_files ifNil: [ 0 ] ifNotNil: 
>> [unsaved_files size].
>>  options := opts sum.
>>  
>>  error := self ffiCall:  #(CXErrorCode 
>> clang_parseTranslationUnit2(CXIndex cxIndex,
>>   String sourceFile,
>>   String *argv,
>>   uint argc,
>>   CXUnsavedFile *unsaved_files,
>>   uint num_unsaved_files,
>>   CXTranslationUnitFlag options,
>>
>> CXTranslationUnit *out_TU)).
>>  
>>  (error = CXError_Success) ifTrue: [ ^out_TU ].
>>  self error: error
>> 
>> Thanks.
>> 
>> 
>>> On Oct 22, 2017, at 2:42 AM, Esteban Lorenzano >> 

Re: [Pharo-dev] feenk log

[Alexandre Bergel]

> Personally (10, 20) for a vector is not really nice and I would really
> like to have a discussion before.

+1 

The Pharo syntax should remain an asset, not become a trap.

Alexandre

> 
> 
> On Wed, Oct 25, 2017 at 6:45 PM, Stephane Ducasse
>  wrote:
>> Doru having a few tweets is nice but I do not think that you
>> communicate well around bloc.
>> 
>> What I would like to get is a roadmap for Bloc V1.0.
>> - Here are the missing features (documentation),
>> - Here are where we are.
>> Because else it feels like Bloc will never ends.
>> You will argue and tell me that you experiments. But without a feature
>> list then
>> people cannot join and do not know when you get a 1.0.
>> 
>> Not measuring is the best way to arrive to a point where you did not wanted.
>> 
>> You see for Brick we need
>>Button
>>CheckBox
>>DropList
>>List
>>Table
>>Pane
>>InputField
>>Text
>>Scrollbar
>>Menu
>> And with that we can get a first Widget set.
>> But again without a roadmap I have some doubts.
>> 
>> Stef
>> 
>> 
>> Stef
>> 
>> 
>> On Wed, Oct 25, 2017 at 6:38 PM, Stephane Ducasse
>>  wrote:
>>> Doru using comma for creating vectors is not really because it will
>>> just make the life of type inferencers more difficult.
>>> 
>>> 
>>> On Wed, Oct 25, 2017 at 5:53 PM, Tudor Girba  wrote:
 Hi,
 
 Our team is working on a couple of projects that are relevant for the core 
 of Pharo, namely GT and Bloc/Brick. At ESUG we were asked by several 
 people, and Stef in particular, to make the progress on these projects 
 more transparent. To this end, we will start two streams of signals:
 - fine grained info bits on out Twitter account (several times a week): 
 https://twitter.com/feenkcom
 - a less often but regular (probably every 2 weeks) activity log message 
 sent to this mailing list
 
 Please let us know if you see an issue with this.
 
 In the meantime, let’s start.
 
 Bloc:
 - Over the past couple of weeks Alex worked on transformations and 
 measurements in the core system. It turns out that there was room for 
 quite a number of performance optimizations and for making the system more 
 debuggable.
 - At the low level, this involved adding matrix and vector support.
 https://twitter.com/feenkcom/status/923123870537863168
 https://twitter.com/feenkcom/status/916300180848349185
 - At a higher level, it implies keeping track of measurements
 https://twitter.com/AliakseiSyrel/status/915203525931622400
 - And of transformations:
 https://twitter.com/feenkcom/status/919603739656417281
 https://twitter.com/feenkcom/status/917116164484096001
 - The BlScalableElement is now working properly
 
 GT Examples:
 - The current repository with unary-based examples is at: 
 https://github.com/feenkcom/gtoolkit-examples
 - We now have a runner in the inspector that allows us to both see the 
 source code and run and play with the resulting object:
 https://twitter.com/feenkcom/status/923210686204989442
 - Andrei made the “after” behavior to work with unary examples.
 
 Cheers,
 The feenk team
 
 --
 www.tudorgirba.com
 www.feenk.com
 
 "Being happy is a matter of choice."
 
 
 
 
 
> 

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  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] Pharo Process question

[Stephane Ducasse]

Well I would dream to give my superpower to attract bugs to anybody else.
Because sometimes this is tiring.
Yesterday a class comment changes of mine broke our jenkins process. Do not
ask me why and how it is possible.
But it did.

Stef

On Wed, Oct 25, 2017 at 12:40 PM, Norbert Hartl  wrote:

> But don't complain for the coming weeks about things not working ;)
>
> Norbert
>
> Am 25.10.2017 um 12:16 schrieb Stephane Ducasse :
>
> Thanks guys.
> Let us move to tonel :)
> So I have to watch out then before pushing the button ;)
> Stef
>
>
> On Wed, Oct 25, 2017 at 10:10 AM, Guillermo Polito <
> guillermopol...@gmail.com> wrote:
>
>>
>>
>> On Tue, Oct 24, 2017 at 9:49 PM, Esteban Lorenzano 
>> wrote:
>>
>>>
>>>
>>> > On 24 Oct 2017, at 21:47, Stephane Ducasse 
>>> wrote:
>>> >
>>> > Hi
>>> >
>>> > are the pending PR reevaluated when one PR is integrated?
>>>
>>
>> Unfortunately not on every integration... We should do it that way but
>> there are some problems with Jenkins allocating space in the master machine.
>>
>> Christophe was telling me he would contact the people from jenkins to see
>> if there is a solution for that.
>>
>>>
>>> it was, but Guille disabled it because it was killing the server.
>>> when we jump to tonel we can re-evaluate the problem :)
>>>
>>> Esteban
>>>
>>> >
>>> > Stef
>>> >
>>>
>>>
>>>
>>
>>
>> --
>>
>> Guille Polito
>> Research Engineer
>>
>>
>> Centre de Recherche en Informatique, Signal et Automatique de Lille
>> CRIStAL - UMR 9189
>> French National Center for Scientific Research - *http://www.cnrs.fr
>> *
>>
>> *Web:* *http://guillep.github.io* 
>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>>
>
>
>

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] feenk log

[Stephane Ducasse]

Personally (10, 20) for a vector is not really nice and I would really
like to have a discussion before.


On Wed, Oct 25, 2017 at 6:45 PM, Stephane Ducasse
 wrote:
> Doru having a few tweets is nice but I do not think that you
> communicate well around bloc.
>
> What I would like to get is a roadmap for Bloc V1.0.
> - Here are the missing features (documentation),
> - Here are where we are.
> Because else it feels like Bloc will never ends.
> You will argue and tell me that you experiments. But without a feature
> list then
> people cannot join and do not know when you get a 1.0.
>
> Not measuring is the best way to arrive to a point where you did not wanted.
>
> You see for Brick we need
> Button
> CheckBox
> DropList
> List
> Table
> Pane
> InputField
> Text
> Scrollbar
> Menu
> And with that we can get a first Widget set.
> But again without a roadmap I have some doubts.
>
> Stef
>
>
> Stef
>
>
> On Wed, Oct 25, 2017 at 6:38 PM, Stephane Ducasse
>  wrote:
>> Doru using comma for creating vectors is not really because it will
>> just make the life of type inferencers more difficult.
>>
>>
>> On Wed, Oct 25, 2017 at 5:53 PM, Tudor Girba  wrote:
>>> Hi,
>>>
>>> Our team is working on a couple of projects that are relevant for the core 
>>> of Pharo, namely GT and Bloc/Brick. At ESUG we were asked by several 
>>> people, and Stef in particular, to make the progress on these projects more 
>>> transparent. To this end, we will start two streams of signals:
>>> - fine grained info bits on out Twitter account (several times a week): 
>>> https://twitter.com/feenkcom
>>> - a less often but regular (probably every 2 weeks) activity log message 
>>> sent to this mailing list
>>>
>>> Please let us know if you see an issue with this.
>>>
>>> In the meantime, let’s start.
>>>
>>> Bloc:
>>> - Over the past couple of weeks Alex worked on transformations and 
>>> measurements in the core system. It turns out that there was room for quite 
>>> a number of performance optimizations and for making the system more 
>>> debuggable.
>>> - At the low level, this involved adding matrix and vector support.
>>> https://twitter.com/feenkcom/status/923123870537863168
>>> https://twitter.com/feenkcom/status/916300180848349185
>>> - At a higher level, it implies keeping track of measurements
>>> https://twitter.com/AliakseiSyrel/status/915203525931622400
>>> - And of transformations:
>>> https://twitter.com/feenkcom/status/919603739656417281
>>> https://twitter.com/feenkcom/status/917116164484096001
>>> - The BlScalableElement is now working properly
>>>
>>> GT Examples:
>>> - The current repository with unary-based examples is at: 
>>> https://github.com/feenkcom/gtoolkit-examples
>>> - We now have a runner in the inspector that allows us to both see the 
>>> source code and run and play with the resulting object:
>>> https://twitter.com/feenkcom/status/923210686204989442
>>> - Andrei made the “after” behavior to work with unary examples.
>>>
>>> Cheers,
>>> The feenk team
>>>
>>> --
>>> www.tudorgirba.com
>>> www.feenk.com
>>>
>>> "Being happy is a matter of choice."
>>>
>>>
>>>
>>>
>>>

Re: [Pharo-dev] feenk log

[Stephane Ducasse]

Doru having a few tweets is nice but I do not think that you
communicate well around bloc.

What I would like to get is a roadmap for Bloc V1.0.
- Here are the missing features (documentation),
- Here are where we are.
Because else it feels like Bloc will never ends.
You will argue and tell me that you experiments. But without a feature
list then
people cannot join and do not know when you get a 1.0.

Not measuring is the best way to arrive to a point where you did not wanted.

You see for Brick we need
Button
CheckBox
DropList
List
Table
Pane
InputField
Text
Scrollbar
Menu
And with that we can get a first Widget set.
But again without a roadmap I have some doubts.

Stef


Stef


On Wed, Oct 25, 2017 at 6:38 PM, Stephane Ducasse
 wrote:
> Doru using comma for creating vectors is not really because it will
> just make the life of type inferencers more difficult.
>
>
> On Wed, Oct 25, 2017 at 5:53 PM, Tudor Girba  wrote:
>> Hi,
>>
>> Our team is working on a couple of projects that are relevant for the core 
>> of Pharo, namely GT and Bloc/Brick. At ESUG we were asked by several people, 
>> and Stef in particular, to make the progress on these projects more 
>> transparent. To this end, we will start two streams of signals:
>> - fine grained info bits on out Twitter account (several times a week): 
>> https://twitter.com/feenkcom
>> - a less often but regular (probably every 2 weeks) activity log message 
>> sent to this mailing list
>>
>> Please let us know if you see an issue with this.
>>
>> In the meantime, let’s start.
>>
>> Bloc:
>> - Over the past couple of weeks Alex worked on transformations and 
>> measurements in the core system. It turns out that there was room for quite 
>> a number of performance optimizations and for making the system more 
>> debuggable.
>> - At the low level, this involved adding matrix and vector support.
>> https://twitter.com/feenkcom/status/923123870537863168
>> https://twitter.com/feenkcom/status/916300180848349185
>> - At a higher level, it implies keeping track of measurements
>> https://twitter.com/AliakseiSyrel/status/915203525931622400
>> - And of transformations:
>> https://twitter.com/feenkcom/status/919603739656417281
>> https://twitter.com/feenkcom/status/917116164484096001
>> - The BlScalableElement is now working properly
>>
>> GT Examples:
>> - The current repository with unary-based examples is at: 
>> https://github.com/feenkcom/gtoolkit-examples
>> - We now have a runner in the inspector that allows us to both see the 
>> source code and run and play with the resulting object:
>> https://twitter.com/feenkcom/status/923210686204989442
>> - Andrei made the “after” behavior to work with unary examples.
>>
>> Cheers,
>> The feenk team
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> "Being happy is a matter of choice."
>>
>>
>>
>>
>>

Re: [Pharo-dev] feenk log

[Stephane Ducasse]

Doru using comma for creating vectors is not really because it will
just make the life of type inferencers more difficult.


On Wed, Oct 25, 2017 at 5:53 PM, Tudor Girba  wrote:
> Hi,
>
> Our team is working on a couple of projects that are relevant for the core of 
> Pharo, namely GT and Bloc/Brick. At ESUG we were asked by several people, and 
> Stef in particular, to make the progress on these projects more transparent. 
> To this end, we will start two streams of signals:
> - fine grained info bits on out Twitter account (several times a week): 
> https://twitter.com/feenkcom
> - a less often but regular (probably every 2 weeks) activity log message sent 
> to this mailing list
>
> Please let us know if you see an issue with this.
>
> In the meantime, let’s start.
>
> Bloc:
> - Over the past couple of weeks Alex worked on transformations and 
> measurements in the core system. It turns out that there was room for quite a 
> number of performance optimizations and for making the system more debuggable.
> - At the low level, this involved adding matrix and vector support.
> https://twitter.com/feenkcom/status/923123870537863168
> https://twitter.com/feenkcom/status/916300180848349185
> - At a higher level, it implies keeping track of measurements
> https://twitter.com/AliakseiSyrel/status/915203525931622400
> - And of transformations:
> https://twitter.com/feenkcom/status/919603739656417281
> https://twitter.com/feenkcom/status/917116164484096001
> - The BlScalableElement is now working properly
>
> GT Examples:
> - The current repository with unary-based examples is at: 
> https://github.com/feenkcom/gtoolkit-examples
> - We now have a runner in the inspector that allows us to both see the source 
> code and run and play with the resulting object:
> https://twitter.com/feenkcom/status/923210686204989442
> - Andrei made the “after” behavior to work with unary examples.
>
> Cheers,
> The feenk team
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Being happy is a matter of choice."
>
>
>
>
>

Re: [Pharo-dev] feenk log

[Denis Kudriashov]

Hi.
Good initiative.

Here is my twitter questions:
- What the reason to introduce BlVector2D instead of using existing Point?
- 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?
Now you can evaluate (10*,* 20)  to get vector instance. And if it is only
to simplify scripting and examples then why not use Point for this? As you
said point can be converted to vector.

Best regards,
Denis


2017-10-25 17:53 GMT+02:00 Tudor Girba :

> Hi,
>
> Our team is working on a couple of projects that are relevant for the core
> of Pharo, namely GT and Bloc/Brick. At ESUG we were asked by several
> people, and Stef in particular, to make the progress on these projects more
> transparent. To this end, we will start two streams of signals:
> - fine grained info bits on out Twitter account (several times a week):
> https://twitter.com/feenkcom
> - a less often but regular (probably every 2 weeks) activity log message
> sent to this mailing list
>
> Please let us know if you see an issue with this.
>
> In the meantime, let’s start.
>
> Bloc:
> - Over the past couple of weeks Alex worked on transformations and
> measurements in the core system. It turns out that there was room for quite
> a number of performance optimizations and for making the system more
> debuggable.
> - At the low level, this involved adding matrix and vector support.
> https://twitter.com/feenkcom/status/923123870537863168
> https://twitter.com/feenkcom/status/916300180848349185
> - At a higher level, it implies keeping track of measurements
> https://twitter.com/AliakseiSyrel/status/915203525931622400
> - And of transformations:
> https://twitter.com/feenkcom/status/919603739656417281
> https://twitter.com/feenkcom/status/917116164484096001
> - The BlScalableElement is now working properly
>
> GT Examples:
> - The current repository with unary-based examples is at:
> https://github.com/feenkcom/gtoolkit-examples
> - We now have a runner in the inspector that allows us to both see the
> source code and run and play with the resulting object:
> https://twitter.com/feenkcom/status/923210686204989442
> - Andrei made the “after” behavior to work with unary examples.
>
> Cheers,
> The feenk team
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> "Being happy is a matter of choice."
>
>
>
>
>
>

Re: [Pharo-dev] [Pharo 7.0-dev] Build #227: 20589-update-iceberg-to-062

[Pavel Krivanek]

copy of the changelog:

v0.6.2

This is a bugfix release.
Issues:

#486 Failing cloning behind a proxy bug
#490 trying to browse an iceberg package in monticello raises error bug
#457 Iceberg fails to parse valid URLs bug
#489 timeout when trying to clone a private gitlab repo bug
#488 remoteurl fails to parse urls with dash ($-) bug
#481 iceberg fails to load private bitbucket repositories bug
#485 Correct usage of bitbucket typed repository
#473 Url handling enhancement

2017-10-25 18:10 GMT+02:00 :

> There is a new Pharo build available!
>
> The status of the build #227 was: SUCCESS.
>
> The Pull Request #397 was integrated: "20589-update-iceberg-to-062"
> Pull request url: https://github.com/pharo-project/pharo/pull/397
>
> Issue Url: https://pharo.fogbugz.com/f/cases/20589
> Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%
> 20pull%20request%20and%20branch%20Pipeline/job/development/227/
>

[Pharo-dev] [Pharo 7.0-dev] Build #227: 20589-update-iceberg-to-062

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #227 was: SUCCESS.

The Pull Request #397 was integrated: "20589-update-iceberg-to-062"
Pull request url: https://github.com/pharo-project/pharo/pull/397

Issue Url: https://pharo.fogbugz.com/f/cases/20589
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/227/

[Pharo-dev] feenk log

[Tudor Girba]

Hi,

Our team is working on a couple of projects that are relevant for the core of 
Pharo, namely GT and Bloc/Brick. At ESUG we were asked by several people, and 
Stef in particular, to make the progress on these projects more transparent. To 
this end, we will start two streams of signals:
- fine grained info bits on out Twitter account (several times a week): 
https://twitter.com/feenkcom
- a less often but regular (probably every 2 weeks) activity log message sent 
to this mailing list

Please let us know if you see an issue with this.

In the meantime, let’s start.

Bloc:
- Over the past couple of weeks Alex worked on transformations and measurements 
in the core system. It turns out that there was room for quite a number of 
performance optimizations and for making the system more debuggable.
- At the low level, this involved adding matrix and vector support.
https://twitter.com/feenkcom/status/923123870537863168
https://twitter.com/feenkcom/status/916300180848349185
- At a higher level, it implies keeping track of measurements 
https://twitter.com/AliakseiSyrel/status/915203525931622400
- And of transformations:
https://twitter.com/feenkcom/status/919603739656417281
https://twitter.com/feenkcom/status/917116164484096001
- The BlScalableElement is now working properly

GT Examples:
- The current repository with unary-based examples is at: 
https://github.com/feenkcom/gtoolkit-examples
- We now have a runner in the inspector that allows us to both see the source 
code and run and play with the resulting object:
https://twitter.com/feenkcom/status/923210686204989442
- Andrei made the “after” behavior to work with unary examples.

Cheers,
The feenk team

--
www.tudorgirba.com
www.feenk.com

"Being happy is a matter of choice."

Re: [Pharo-dev] Bloc Feedback

[Tudor Girba]

Hi Sean,

> On Oct 25, 2017, at 2:14 PM, Sean P. DeNigris  wrote:
> 
> Aliaksei Syrel wrote
>> I don't understand how you guys find these kind of bugs :D
> 
> We have a talent for destruction ;)
> 
> 
> Aliaksei Syrel wrote
>> Aha, I forgot about it, thanks! At this point BlTextEditElement is only
>> used internally by Moldable Editor so I will probably move it away from
>> Bloc.
> 
> Ah, okay. IHMO at least a basic editable text morph (and ideally a real
> editor morph as well) is essential to people starting to
> play/experiment/test Bloc for real.

I think there is a misunderstanding.

We distinguish between Bloc and Brick:
- Bloc offers the basic management of graphical elements (including layouts, 
measurements, transformation etc)
- Brick offers widgets

In Bloc, there exists a basic text widget, but the full fledged moldable editor 
is part of Brick.

While it is important to have Bloc as a generic infrastructure, coming from 
Morphic you just can look at Bloc and Brick as being one.

Doru

> Aliaksei Syrel wrote
>> Thanks for the feedback :)
> 
> Sure! Any thoughts on this:
>> 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?… I guess I mean what is
>> the 
>> Bloc version of #step that would enable us to do e.g. Squeak's 
>> mouse-eyes-tracking-the-cursor or Lively Kernel's clock:
>>  
> 
> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
> 

--
www.tudorgirba.com
www.feenk.com

"Being happy is a matter of choice."

Re: [Pharo-dev] UnifiedFFI Docs

[Esteban Lorenzano]

:)

Did you look at this project: 
https://github.com/estebanlm/libclang-pharo-bindings/ 
 ?

it was using parseTranslationUnit (no 2)… there you can find how is being used 
(I just converted it to tonel format, but older versions are in filetree)

Esteban

> On 24 Oct 2017, at 19:17, Todd Blanchard  wrote:
> 
> Hey Esteban,
> 
> Now that you have outed yourself as a maintainer of FFI, I have a question. 
> :-)
> 
> I want to call the libclang function:
> 
> /**
> * \brief Parse the given source file and the translation unit corresponding
> * to that file.
> *
> * This routine is the main entry point for the Clang C API, providing the
> * ability to parse a source file into a translation unit that can then be
> * queried by other functions in the API. This routine accepts a set of
> * command-line arguments so that the compilation can be configured in the same
> * way that the compiler is configured on the command line.
> *
> * \param CIdx The index object with which the translation unit will be 
> * associated.
> *
> * \param source_filename The name of the source file to load, or NULL if the
> * source file is included in \c command_line_args.
> *
> * \param command_line_args The command-line arguments that would be
> * passed to the \c clang executable if it were being invoked out-of-process.
> * These command-line options will be parsed and will affect how the 
> translation
> * unit is parsed. Note that the following options are ignored: '-c', 
> * '-emit-ast', '-fsyntax-only' (which is the default), and '-o \ file>'.
> *
> * \param num_command_line_args The number of command-line arguments in
> * \c command_line_args.
> *
> * \param unsaved_files the files that have not yet been saved to disk
> * but may be required for parsing, including the contents of
> * those files.  The contents and name of these files (as specified by
> * CXUnsavedFile) are copied when necessary, so the client only needs to
> * guarantee their validity until the call to this function returns.
> *
> * \param num_unsaved_files the number of unsaved file entries in \p
> * unsaved_files.
> *
> * \param options A bitmask of options that affects how the translation unit
> * is managed but not its compilation. This should be a bitwise OR of the
> * CXTranslationUnit_XXX flags.
> *
> * \param[out] out_TU A non-NULL pointer to store the created
> * \c CXTranslationUnit, describing the parsed code and containing any
> * diagnostics produced by the compiler.
> *
> * \returns Zero on success, otherwise returns an error code.
> */
> enum CXErrorCode
> clang_parseTranslationUnit2(CXIndex CIdx,
>const char *source_filename,
>const char *const *command_line_args,
>int num_command_line_args,
>struct CXUnsavedFile *unsaved_files,
>unsigned num_unsaved_files,
>unsigned options,
>CXTranslationUnit *out_TU);
> 
> The parts I'm not clear on are turning an array or ordered collection of 
> strings into an argv/argc, turning an array of CXUnsavedFile's 
> (FFIExternalStruct) into an array of pointers and count, and getting data 
> back in an output argument as CXTranslationUnit which is an opaque pointer to 
> a C++ object.
> 
> Any tips on these mappings would be great.  I've currently guessed it as:
> 
> clang_parseTranslationUnit__cxIndex: cxIndex source: sourceFile arguments: 
> argv unsavedFiles:unsaved options: opts
> 
>   | argc unsaved_files num_unsaved_files options error out_TU |
>   argc := argv size.
>   unsaved_files := unsaved ifNil: [ #() ] ifNotNil: [ unsaved ]. 
>   num_unsaved_files := unsaved_files ifNil: [ 0 ] ifNotNil: 
> [unsaved_files size].
>   options := opts sum.
>   
>   error := self ffiCall:  #(CXErrorCode 
> clang_parseTranslationUnit2(CXIndex cxIndex,
>   String sourceFile,
>   String *argv,
>   uint argc,
>   CXUnsavedFile *unsaved_files,
>   uint num_unsaved_files,
>   CXTranslationUnitFlag options,
> 
> CXTranslationUnit *out_TU)).
>   
>   (error = CXError_Success) ifTrue: [ ^out_TU ].
>   self error: error
> 
> Thanks.
> 
> 
>> On Oct 22, 2017, at 2:42 AM, Esteban Lorenzano  wrote:
>> 
>> Hi, 
>> 
>>> On 21 Oct 2017, at 21:15, Stephane Ducasse  wrote:
>>> 
>>> Esteban will probably reply to this thread
>> 
>> yes, I will :)
>> 
>>> 
>>> 
>>> On Thu, Oct 19, 2017 at 10:34 PM, Todd Blanchard  wrote:
 I have found the problem with VoidPointer3 generating accessors.
>> 
>> can you 

Re: [Pharo-dev] Bloc Feedback

[Sean P. DeNigris]

Aliaksei Syrel wrote
> I don't understand how you guys find these kind of bugs :D

We have a talent for destruction ;)


Aliaksei Syrel wrote
> Aha, I forgot about it, thanks! At this point BlTextEditElement is only
> used internally by Moldable Editor so I will probably move it away from
> Bloc.

Ah, okay. IHMO at least a basic editable text morph (and ideally a real
editor morph as well) is essential to people starting to
play/experiment/test Bloc for real.


Aliaksei Syrel wrote
> Thanks for the feedback :)

Sure! Any thoughts on this:
> 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?… I guess I mean what is
> the 
> Bloc version of #step that would enable us to do e.g. Squeak's 
> mouse-eyes-tracking-the-cursor or Lively Kernel's clock:
>  




-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] [ANN] sha256 checksum for Pharo6 downloads

[Sven Van Caekenberghe]

> On 25 Oct 2017, at 14:02, Sean P. DeNigris  wrote:
> 
> Sven Van Caekenberghe-2 wrote
>> And here is how to do it in Pharo…
> 
> It would be great to add something like this to Launcher

Yeah, but 

 file readStreamDo: [ :in | sha256 := SHA256 hashStream: in ].

is very slow (done completely in Pharo, large file), so it would need a good 
progress bar.

We would also need a canonical place to get the signatures from (like Marcus 
explained, best another, secure server).

Sven

Re: [Pharo-dev] [ANN] sha256 checksum for Pharo6 downloads

[Sean P. DeNigris]

Sven Van Caekenberghe-2 wrote
> And here is how to do it in Pharo…

It would be great to add something like this to Launcher



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Re: [Pharo-dev] Bloc status

[Juraj Kubelka]

That’s great it works for you. Be careful that using Metacello baseline script 
does not update the local GIT repositories to the latest versions. Check my 
recent post in Moose: 
http://forum.world.st/RTExampleFactory-is-missing-sourceClass-tp4990173p4991063.html
 

 

So, check in Iceberg that all GIT repositories are up-to-date. 

Cheers,
Juraj

> On Oct 24, 2017, at 19:02, Sean P. DeNigris  wrote:
> 
> Juraj Kubelka wrote
>> Or you may share repositories among images… kIceRepository
>> sharedRepositoriesLocationString
> 
> That was it! It was
> {IcebergSharedRepoFolder}/feenkcom/gtoolkit-visualizer/doc/mondrian/index.pillar
> 
> Now that I can see the presentations… Super cool!! Putting more $! in front
> of a line -> text auto-shrinks :)
> 
> Two issues:
> 1. For the live examples in the Bloc-Pillar tab: "MNU receiver of #gtLiveIn:
> is nil"
> 2. In the Pillar tab, the headings are unreadable with the dark theme:
>  
> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
> 

Re: [Pharo-dev] Pharo Process question

[Norbert Hartl]

But don't complain for the coming weeks about things not working ;)

Norbert

> Am 25.10.2017 um 12:16 schrieb Stephane Ducasse :
> 
> Thanks guys.
> Let us move to tonel :)
> So I have to watch out then before pushing the button ;)
> Stef
> 
> 
> On Wed, Oct 25, 2017 at 10:10 AM, Guillermo Polito  > wrote:
> 
> 
> On Tue, Oct 24, 2017 at 9:49 PM, Esteban Lorenzano  > wrote:
> 
> 
> > On 24 Oct 2017, at 21:47, Stephane Ducasse  > > wrote:
> >
> > Hi
> >
> > are the pending PR reevaluated when one PR is integrated?
> 
> Unfortunately not on every integration... We should do it that way but there 
> are some problems with Jenkins allocating space in the master machine.
> 
> Christophe was telling me he would contact the people from jenkins to see if 
> there is a solution for that.
> 
> it was, but Guille disabled it because it was killing the server.
> when we jump to tonel we can re-evaluate the problem :)
> 
> Esteban
> 
> >
> > Stef
> >
> 
> 
> 
> 
> 
> -- 
>
> Guille Polito
> Research Engineer
> 
> Centre de Recherche en Informatique, Signal et Automatique de Lille
> CRIStAL - UMR 9189
> French National Center for Scientific Research - http://www.cnrs.fr 
> 
> 
> Web: http://guillep.github.io 
> Phone: +33 06 52 70 66 13 

Re: [Pharo-dev] Pharo Process question

[Stephane Ducasse]

Thanks guys.
Let us move to tonel :)
So I have to watch out then before pushing the button ;)
Stef


On Wed, Oct 25, 2017 at 10:10 AM, Guillermo Polito <
guillermopol...@gmail.com> wrote:

>
>
> On Tue, Oct 24, 2017 at 9:49 PM, Esteban Lorenzano 
> wrote:
>
>>
>>
>> > On 24 Oct 2017, at 21:47, Stephane Ducasse 
>> wrote:
>> >
>> > Hi
>> >
>> > are the pending PR reevaluated when one PR is integrated?
>>
>
> Unfortunately not on every integration... We should do it that way but
> there are some problems with Jenkins allocating space in the master machine.
>
> Christophe was telling me he would contact the people from jenkins to see
> if there is a solution for that.
>
>>
>> it was, but Guille disabled it because it was killing the server.
>> when we jump to tonel we can re-evaluate the problem :)
>>
>> Esteban
>>
>> >
>> > Stef
>> >
>>
>>
>>
>
>
> --
>
>
>
> Guille Polito
>
> Research Engineer
>
> Centre de Recherche en Informatique, Signal et Automatique de Lille
>
> CRIStAL - UMR 9189
>
> French National Center for Scientific Research - *http://www.cnrs.fr
> *
>
>
> *Web:* *http://guillep.github.io* 
>
> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013>
>

[Pharo-dev] [ANN] LAM Research upgraded to Platinum Membership

[Marcus Denker]

The Pharo Consortium is very happy to announce that LAM Research 
has upgraded to Platinum Member status.

About
- LAM Research: http://www.lamresearch.com
- Pharo Consortium: http://consortium.pharo.org

The goal of the Pharo Consortium is to allow companies and institutions to
support the ongoing development and future of Pharo.

Individuals can support Pharo via the Pharo Association:

  http://association.pharo.org

Re: [Pharo-dev] [ANN] sha256 checksum for Pharo6 downloads

[Marcus Denker]

>> 
>>> Would it not be cleaner if the signature was next to the resource ? Like 
>>> 
>>> http://files.pharo.org/platform/Pharo6.1-mac.zip.sha256.txt
>>> 
>>> Or is that the next step ?
>>> 
>> 
>> Already there. But a signature like that is not a guarantee if it is 
>> downloaded from the same server… especially of that server does not
>> use SSL… 
>> 
>> The “stack vector” that a checksum protects against is the compromise of a 
>> download server, especially untrusted mirrors. For that, 
>> the checksum needs to come from some other (trusted) source. E.g. normally 
>> it is inlined on the download website.
>> 
>> But of course these things are never 100% guarantees, they just make it 
>> harder to do bad things.
> 
> Ah, OK, I understand, I just think that a shorter/simpler/easier-to-remember 
> URL for the signature would be better.
> 
I will put them on pharo.org  later, too (in a dedicated 
directory). And link them from the download page.

Marcus

Re: [Pharo-dev] [ANN] sha256 checksum for Pharo6 downloads

[Sven Van Caekenberghe]

> On 25 Oct 2017, at 10:33, Marcus Denker  wrote:
> 
> 
> 
>> On 25 Oct 2017, at 10:23, Sven Van Caekenberghe  wrote:
>> 
>> Great!
>> 
>> And here is how to do it in Pharo:
>> 
>> signature := 
>> 'https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-5-Publish/lastSuccessfulBuild/artifact/Pharo6.1-mac.zip.sha256.txt'
>>  asUrl retrieveContents findTokens: Character separators.
>> hash := signature first.
>> signedFile := signature second.
>> url := 'http://files.pharo.org/platform/Pharo6.1-mac.zip' asUrl.
>> ZnClient new url: url; downloadTo: FileLocator temp. "somewhat slow"
>> file := FileLocator temp / url file.
>> self assert: file exists.
>> self assert: (signedFile match: url file).
>> file readStreamDo: [ :in | sha256 := SHA256 hashStream: in ]. "very slow"
>> self assert: (hash sameAs: sha256 hex).
>> 
> Nice!
> 
>> Would it not be cleaner if the signature was next to the resource ? Like 
>> 
>> http://files.pharo.org/platform/Pharo6.1-mac.zip.sha256.txt
>> 
>> Or is that the next step ?
>> 
> 
> Already there. But a signature like that is not a guarantee if it is 
> downloaded from the same server… especially of that server does not
> use SSL… 
> 
> The “stack vector” that a checksum protects against is the compromise of a 
> download server, especially untrusted mirrors. For that, 
> the checksum needs to come from some other (trusted) source. E.g. normally it 
> is inlined on the download website.
> 
> But of course these things are never 100% guarantees, they just make it 
> harder to do bad things.

Ah, OK, I understand, I just think that a shorter/simpler/easier-to-remember 
URL for the signature would be better.

>   Marcus

Re: [Pharo-dev] [ANN] sha256 checksum for Pharo6 downloads

[Marcus Denker]

> On 25 Oct 2017, at 10:33, Marcus Denker  wrote:
> 
> 
> 
>> On 25 Oct 2017, at 10:23, Sven Van Caekenberghe  wrote:
>> 
>> Great!
>> 
>> And here is how to do it in Pharo:
>> 
>> signature := 
>> 'https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-5-Publish/lastSuccessfulBuild/artifact/Pharo6.1-mac.zip.sha256.txt'
>>  asUrl retrieveContents findTokens: Character separators.
>> hash := signature first.
>> signedFile := signature second.
>> url := 'http://files.pharo.org/platform/Pharo6.1-mac.zip' asUrl.
>> ZnClient new url: url; downloadTo: FileLocator temp. "somewhat slow"
>> file := FileLocator temp / url file.
>> self assert: file exists.
>> self assert: (signedFile match: url file).
>> file readStreamDo: [ :in | sha256 := SHA256 hashStream: in ]. "very slow"
>> self assert: (hash sameAs: sha256 hex).
>> 
> Nice!
> 
>> Would it not be cleaner if the signature was next to the resource ? Like 
>> 
>> http://files.pharo.org/platform/Pharo6.1-mac.zip.sha256.txt
>> 
>> Or is that the next step ?
>> 
> 
> Already there. But a signature like that is not a guarantee if it is 
> downloaded from the same server… especially of that server does not
> use SSL… 
> 
> The “stack vector” 
   Attack vector

Re: [Pharo-dev] [ANN] sha256 checksum for Pharo6 downloads

[Marcus Denker]

> On 25 Oct 2017, at 10:23, Sven Van Caekenberghe  wrote:
> 
> Great!
> 
> And here is how to do it in Pharo:
> 
> signature := 
> 'https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-5-Publish/lastSuccessfulBuild/artifact/Pharo6.1-mac.zip.sha256.txt'
>  asUrl retrieveContents findTokens: Character separators.
> hash := signature first.
> signedFile := signature second.
> url := 'http://files.pharo.org/platform/Pharo6.1-mac.zip' asUrl.
> ZnClient new url: url; downloadTo: FileLocator temp. "somewhat slow"
> file := FileLocator temp / url file.
> self assert: file exists.
> self assert: (signedFile match: url file).
> file readStreamDo: [ :in | sha256 := SHA256 hashStream: in ]. "very slow"
> self assert: (hash sameAs: sha256 hex).
> 
Nice!

> Would it not be cleaner if the signature was next to the resource ? Like 
> 
> http://files.pharo.org/platform/Pharo6.1-mac.zip.sha256.txt
> 
> Or is that the next step ?
> 

Already there. But a signature like that is not a guarantee if it is downloaded 
from the same server… especially of that server does not
use SSL… 

The “stack vector” that a checksum protects against is the compromise of a 
download server, especially untrusted mirrors. For that, 
the checksum needs to come from some other (trusted) source. E.g. normally it 
is inlined on the download website.

But of course these things are never 100% guarantees, they just make it harder 
to do bad things.

Marcus

Re: [Pharo-dev] [ANN] sha256 checksum for Pharo6 downloads

[Sven Van Caekenberghe]

Great!

And here is how to do it in Pharo:

signature := 
'https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-5-Publish/lastSuccessfulBuild/artifact/Pharo6.1-mac.zip.sha256.txt'
 asUrl retrieveContents findTokens: Character separators.
hash := signature first.
signedFile := signature second.
url := 'http://files.pharo.org/platform/Pharo6.1-mac.zip' asUrl.
ZnClient new url: url; downloadTo: FileLocator temp. "somewhat slow"
file := FileLocator temp / url file.
self assert: file exists.
self assert: (signedFile match: url file).
file readStreamDo: [ :in | sha256 := SHA256 hashStream: in ]. "very slow"
self assert: (hash sameAs: sha256 hex).

Would it not be cleaner if the signature was next to the resource ? Like 

http://files.pharo.org/platform/Pharo6.1-mac.zip.sha256.txt

Or is that the next step ?

> On 25 Oct 2017, at 09:53, Marcus Denker  wrote:
> 
> How to validate a Pharo6 download with the example of the mac download:
> 
> 1) get the checksum file (note: uses SSL):
>   
> https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-5-Publish/lastSuccessfulBuild/artifact/Pharo6.1-mac.zip.sha256.txt
> 
> 2) download Pharo:
>   http://files.pharo.org/platform/Pharo6.1-mac.zip
> 
> with sha256sum installed, you can do:
> 
>   sha256sum -c Pharo6.1-mac.zip.sha256.txt
> 
> and it prints:
> 
> Pharo6.1-mac.zip: OK
> 
>   Marcus
> 
> 
>> On 24 Oct 2017, at 17:34, Marcus Denker  wrote:
>> 
>> Hi,
>> 
>> A tiny first step: I added sha256 chechsums for all downloads created by the 
>> Pharo6 build process
>> 
>>  https://ci.inria.fr/pharo/
>> 
>> This step:
>> 
>>  https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-5-Publish/
>> 
>> now creates .sha256.txt files, e.g for the mac:
>> 
>>  
>> https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-5-Publish/lastSuccessfulBuild/artifact/Pharo6.1-mac.zip.sha256.txt
>> 
>> This allows to check that downloads from the file server are indeed the same 
>> files that the build server created.
>>  http://files.pharo.org/platform/
>>  http://files.pharo.org/image/60/
>> 
>> 
>> As I said, just a very first step.
>> 
>> TODO:
>>  - pgp signatures 
>>  - insert into website
>>  - SSL for files.pharo.org
>>  - do it Pharo7  
>>  - ….
>> 
>> So: more to come!
>> 
>>  Marcus
> 
> 

Re: [Pharo-dev] Pharo Process question

[Guillermo Polito]

On Tue, Oct 24, 2017 at 9:49 PM, Esteban Lorenzano 
wrote:

>
>
> > On 24 Oct 2017, at 21:47, Stephane Ducasse 
> wrote:
> >
> > Hi
> >
> > are the pending PR reevaluated when one PR is integrated?
>

Unfortunately not on every integration... We should do it that way but
there are some problems with Jenkins allocating space in the master machine.

Christophe was telling me he would contact the people from jenkins to see
if there is a solution for that.

>
> it was, but Guille disabled it because it was killing the server.
> when we jump to tonel we can re-evaluate the problem :)
>
> Esteban
>
> >
> > Stef
> >
>
>
>


-- 



Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr
*


*Web:* *http://guillep.github.io* 

*Phone: *+33 06 52 70 66 13

Re: [Pharo-dev] [ANN] sha256 checksum for Pharo6 downloads

[Marcus Denker]

How to validate a Pharo6 download with the example of the mac download:

1) get the checksum file (note: uses SSL):

https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-5-Publish/lastSuccessfulBuild/artifact/Pharo6.1-mac.zip.sha256.txt

2) download Pharo:
http://files.pharo.org/platform/Pharo6.1-mac.zip

with sha256sum installed, you can do:

sha256sum -c Pharo6.1-mac.zip.sha256.txt

and it prints:

Pharo6.1-mac.zip: OK

Marcus


> On 24 Oct 2017, at 17:34, Marcus Denker  wrote:
> 
> Hi,
> 
> A tiny first step: I added sha256 chechsums for all downloads created by the 
> Pharo6 build process
> 
>   https://ci.inria.fr/pharo/
> 
> This step:
> 
>   https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-5-Publish/
> 
> now creates .sha256.txt files, e.g for the mac:
> 
>   
> https://ci.inria.fr/pharo/job/Pharo-6.0-Update-Step-5-Publish/lastSuccessfulBuild/artifact/Pharo6.1-mac.zip.sha256.txt
> 
> This allows to check that downloads from the file server are indeed the same 
> files that the build server created.
>   http://files.pharo.org/platform/
>   http://files.pharo.org/image/60/
> 
> 
> As I said, just a very first step.
> 
> TODO:
>   - pgp signatures 
>   - insert into website
>   - SSL for files.pharo.org
>   - do it Pharo7  
>   - ….
> 
> So: more to come!
> 
>   Marcus

Re: [Pharo-dev] Bloc status

[Tudor Girba]

Hi,


> On Oct 25, 2017, at 12:02 AM, Sean P. DeNigris  wrote:
> 
> Juraj Kubelka wrote
>> Or you may share repositories among images… kIceRepository
>> sharedRepositoriesLocationString
> 
> That was it! It was
> {IcebergSharedRepoFolder}/feenkcom/gtoolkit-visualizer/doc/mondrian/index.pillar
> 
> Now that I can see the presentations… Super cool!! Putting more $! in front
> of a line -> text auto-shrinks :)
> 
> Two issues:
> 1. For the live examples in the Bloc-Pillar tab: "MNU receiver of #gtLiveIn:
> is nil”

Which live examples raise the MNU?

Doru

> 2. In the Pillar tab, the headings are unreadable with the dark theme:
>  
> 
> 
> 
> -
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html
> 

--
www.tudorgirba.com
www.feenk.com

“Programming is executable philosophy."

[Pharo-dev] [Pharo 7.0-dev] Build #226: 20569-Update-Layout-class-comment

[ci-pharo-ci-jenkins2]

There is a new Pharo build available!

The status of the build #226 was: SUCCESS.

The Pull Request #385 was integrated: "20569-Update-Layout-class-comment"
Pull request url: https://github.com/pharo-project/pharo/pull/385

Issue Url: https://pharo.fogbugz.com/f/cases/20569
Build Url: 
https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/development/226/