- Pharo-dev - lists.pharo.org

, for vector creation

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

Oct. 25, 2017

Re: [Pharo-dev] feenk log

by 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 <alexandre.bergel(a)me.com> 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 >> <stepharo.self(a)gmail.com> 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 >>> <stepharo.self(a)gmail.com> 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 <tudor(a)tudorgirba.com> 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."

Oct. 25, 2017

Re: [Pharo-dev] feenk log

by 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 <stepharo.self(a)gmail.com> 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 > <stepharo.self(a)gmail.com> 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 <tudor(a)tudorgirba.com> 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."

Oct. 25, 2017

Re: [Pharo-dev] UnifiedFFI Docs

by 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 <estebanlm(a)gmail.com> wrote: > > :) > > Did you look at this project: https://github.com/estebanlm/libclang-pharo-bindings/ <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 <tblanchard(a)mac.com <mailto:tblanchard@mac.com>> 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 \<output 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 <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: >>> >>> Hi, >>> >>>> On 21 Oct 2017, at 21:15, Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> wrote: >>>> >>>> Esteban will probably reply to this thread >>> >>> yes, I will :) >>> >>>> >>>> >>>> On Thu, Oct 19, 2017 at 10:34 PM, Todd Blanchard <tblanchard(a)mac.com <mailto:tblanchard@mac.com>> wrote: >>>>> I have found the problem with VoidPointer3 generating accessors. >>> >>> can you report that on fogbugz ? >>> (along with your solution) >>> >>> thanks! >>> Esteban >>> >>>>> >>>>> No idea how to contribute back a fix but this is what I've found. >>>>> >>>>> FFITypeArrayType>>annonymousClassCreator >>>>> ^ String streamContents: [ :stream | >>>>> stream >>>>> nextPutAll: '(FFITypeArray ofType: '; >>>>> print: (self objectClass type isPointer ifTrue: [self externalTypeWithArity >>>>> printString] ifFalse: ['#',self objectClass type class]); >>>>> nextPutAll: ' size: '; >>>>> print: self objectClass numberOfElements; >>>>> nextPutAll: ')' ] >>>>> >>>>> Recalling that we are trying to come up with an accessor that can pull out a >>>>> void*[3], this produces >>>>> >>>>> '(FFITypeArray ofType: #FFIVoid size: 3)' >>>>> >>>>> which produces an error as FFIVoid's size is undefined. In general, this >>>>> will be wrong for any pointer type and will probably get the size >>>>> calculation wrong. >>>>> >>>>> Doing a little digging I find that >>>>> >>>>> FFITypeArray>>ofType: aType size: aSize >>>>> >>>>> delegates resolution of aType to FFIExternalType>>resolveType:aType and this >>>>> can take all kinds of different things including the native type name. >>>>> >>>>> It would be better if this generated the native name for pointers. >>>>> >>>>> (FFITypeArray ofType: 'void*' size: 3) >>>>> >>>>> So I changed it to: >>>>> >>>>> FFITypeArrayType>>annonymousClassCreator >>>>> ^ String streamContents: [ :stream | >>>>> stream >>>>> nextPutAll: '(FFITypeArray ofType: '; >>>>> print: (self objectClass type isPointer >>>>> ifTrue: [self externalTypeWithArity printString] >>>>> ifFalse: ['#',self objectClass type class]); >>>>> nextPutAll: ' size: '; >>>>> print: self objectClass numberOfElements; >>>>> nextPutAll: ')' ] >>>>> >>>>> and this seems to work fine. >>>>> >>>>> Onwards... >>>>> >>>>> On Oct 19, 2017, at 7:18 AM, Todd Blanchard <tblanchard(a)mac.com <mailto:tblanchard@mac.com>> wrote: >>>>> >>>>> Thatâs great - itâs been kind of magical but a couple things have changed >>>>> since you wrote it and some bugs have crept into ffi. >>>>> >>>>> Right now Iâm finding the generated accessor for the VoidPointer3 is >>>>> actually generating a void 3 accessor and that doesnât work. I spent all day >>>>> yesterday tracking it to the accessor generating code. >>>>> >>>>> Sent from the road >>>>> >>>>> On Oct 18, 2017, at 22:29, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: >>>>> >>>>> >>>>> >>>>> On Thu, Oct 19, 2017 at 1:05 AM, Todd Blanchard <tblanchard(a)mac.com <mailto:tblanchard@mac.com>> wrote: >>>>>> >>>>>> I'm working through Ben's great blog post about playing with libclang and >>>>>> I am puzzled by something. >>>>> >>>>> >>>>> Thx Todd. Knowing someone is looking at it encourages me to expand it. >>>>> I'm interested in looking at your specific questions, but it might not be >>>>> until next week after this stint of long work days. >>>>> >>>>> cheers -ben >>>>> >>>>> >>>>>> >>>>>> >>>>>> invalidateSessionData >>>>>> handle atAllPut: 0. >>>>>> >>>>>> zero;s out the handle. Cool. However, >>>>>> >>>>>> handle isNull >>>>>> >>>>>> does not return true despite it being used in the getString method as >>>>>> >>>>>> ^ handle isNull >>>>>> ifTrue: ['external memory invalidated by session restart'] >>>>>> ifFalse:[LibClang clang_getCString__cxString: self]. >>>>>> >>>>>> Looks like there should be an isNull on ByteArray that returns true if all >>>>>> bytes are zero but it isn't there. Was it dropped for some reason? >>>>>> >>>>>> >>>>>> >>>>>> On Oct 18, 2017, at 2:58 AM, Dimitris Chloupis <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> >>>>>> wrote: >>>>>> >>>>>> Sure the documentation could be better, that is definetly important, but >>>>>> is already good enough and UFFI is a very technical subject much more suited >>>>>> to a mailing list . Its not physical possible to cover the massive potential >>>>>> of UFFI. >>>>>> >>>>>> On Wed, Oct 18, 2017 at 9:32 AM Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> >>>>>> wrote: >>>>>>> >>>>>>> Please do not hesitate to do Pull Requests. >>>>>>> Luc told me that he wants to do a pass on it and Esteban promises that to >>>>>>> me >>>>>>> but he is super busy. >>>>>>> >>>>>>> Stef >>>>>>> >>>>>>> >>>>>>> On Wed, Oct 18, 2017 at 5:54 AM, Todd Blanchard <tblanchard(a)mac.com <mailto:tblanchard@mac.com>> >>>>>>> wrote: >>>>>>>> Wonderful! Thanks. >>>>>>>> >>>>>>>>> On Oct 17, 2017, at 3:45 PM, stephan <stephan(a)stack.nl <mailto:stephan@stack.nl>> wrote: >>>>>>>>> >>>>>>>>> On 17-10-17 23:06, Todd Blanchard wrote: >>>>>>>>>> Anyone know what happened to this? >>>>>>>>>> >>>>>>>>>> https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre… <https://ci.inria.fr/pharo-contribution/view/Books/job/PharoBookWorkInProgre…> >>>>>>>>> >>>>>>>>> https://github.com/SquareBracketAssociates/Booklet-uFFI <https://github.com/SquareBracketAssociates/Booklet-uFFI> >>>>>>>>> >>>>>>>>> has a link to a bintray pdf download >>>>>>>>> >>>>>>>>> Stephan >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> >

Oct. 25, 2017

Re: [Pharo-dev] feenk log

by 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 > <stepharo.self(a)gmail.com> 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 >> <stepharo.self(a)gmail.com> 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 <tudor(a)tudorgirba.com> 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." >>>> >>>> >>>> >>>> >>>> >

Oct. 25, 2017

Re: [Pharo-dev] feenk log

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

Oct. 25, 2017

Re: [Pharo-dev] Pharo Process question

by 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 <norbert(a)hartl.name> wrote: > But don't complain for the coming weeks about things not working ;) > > Norbert > > Am 25.10.2017 um 12:16 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: > > 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 < > guillermopolito(a)gmail.com> wrote: > >> >> >> On Tue, Oct 24, 2017 at 9:49 PM, Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >>> >>> >>> > On 24 Oct 2017, at 21:47, Stephane Ducasse <stepharo.self(a)gmail.com> >>> 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 >> <http://www.cnrs.fr/>* >> >> *Web:* *http://guillep.github.io* <http://guillep.github.io/> >> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >> > > >

Oct. 25, 2017

Re: [Pharo-dev] feenk log

by 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

Oct. 25, 2017

Re: [Pharo-dev] feenk log

by 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 <stepharo.self(a)gmail.com> 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 > <stepharo.self(a)gmail.com> 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 <tudor(a)tudorgirba.com> 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." >>> >>> >>> >>> >>>

Oct. 25, 2017

Re: [Pharo-dev] feenk log

by 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 <stepharo.self(a)gmail.com> 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 <tudor(a)tudorgirba.com> 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." >> >> >> >> >>

Oct. 25, 2017