- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] feenk log

by 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 <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 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 <tudor(a)tudorgirba.com>: > 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] [Pharo 7.0-dev] Build #227: 20589-update-iceberg-to-062

by 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 <ci-pharo-ci-jenkins2(a)inria.fr>: > 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/ >

Oct. 25, 2017

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

by ci-pharo-ci-jenkins2＠inria.fr

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%2…

Oct. 25, 2017

Re: [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change considerations

by henry

I disabled vatId authorization in version 3, located in SessionOperations>>processIWant | SessionOperations>>processIAm:. I was asked to disseminate my news to Pharo Users, hello there. I was asked to describe ParrotTalk well, provide use cases and adopters of its use. Alright, I will give an attempt. ParrotTalk is an encrypted connection framework. Currently allowing anonymous 2048-bit key negotiation to establish user-provided encryption cipher and user-provided encoding and decoding, both through a provided SessionAgentMap to a starting SessionAgent server. Please look in the test case ThunkHelloWorldTest for building these maps and running a connection iwth data passing after encryption is established. There is a 4-way negotiation, from ProtocolOffered/Accepted to Go/GoToo. In using RSA 2048 signature validation and DH 2048 primes to establish the key used within the selected Cipher. The Cipher and Encoder are selected by name through the negotiation protocol. Currently three Ciphers are selectable, AESede, DESede, and DES. There are two encoders tested, asn1der, and Bytes. This protocol is described here, in this document. https://github.com/ZiroZimbarra/callistohouse/blob/master/docs/ParrotTalkFr… For as to use cases, this encrypted connection has no third party, man-in-the-middle situation by not using Certificates. As such, this is a tight implementation of NSA-proof encryption without explicit authorization beyond knowledge of a host:port. The use cases involve any communication desired to be encrypted with such high encryption. The support will last my lifetime, so we have a settled solution, here in the third version, provided here. It requires version 111 of Cryptography, as a prerequisite. Both run on Squeak and Pharo. http://www.squeaksource.com/Cryptography/Cryptography-zzz.111.mcz http://www.squeaksource.com/Cryptography/ParrotTalk-HenryHouse.3.mcz The current use is with my hubbub system, a promise-based distributed object implementation. I am working to bring ParrotTalk to Java and allow hubbub to operate interdependently between Squeak, Pharo, Java and any other languages which can support ParrotTalk and STON. My latest efforts with hubbub are to bring STON as the Layer 6 encoding. Hubbub depends on eLinda. http://www.squeaksource.com/Cryptography/elinda-HenryHouse.14.mcz http://www.squeaksource.com/Oceanside/hubbub-HenryHouse.38.mcz Hubbub currently fails to load correctly in Pharo. In Squeak the two ParrotRemoteTestCases: LookupTestCase and OperationalTestCase really screw everything up, do not save an image after running. I never run these tests until I get a better handle of serialization. Currently, do to a shift in progress to STON, the serialization tests fail, just the way we like it. Fix the tests then the system starts to work right. The shift away from vatId authorization should not adversely affect hubbub, we hope! When STON starts to work, and I think I need to turn off jsonMode, then traffic between vats can start to be analyzed and figure out how resolving is working with redirectors invoked remotely. - HH > -------- Original Message -------- > Subject: Re: [Pharo-dev] [ANNOUNCE] ParrotTalk release/design change considerations > Local Time: October 25, 2017 12:43 AM > UTC Time: October 25, 2017 4:43 AM > From: btc(a)openinworld.com > To: henry <henry(a)callistohouse.club>, Pharo Development List <pharo-dev(a)lists.pharo.org> > Stephane Ducasse <stepharo.self(a)gmail.com> > > If I google... parrottalk protocol > nothing seems related. So what is ParrotTalk? > > P.S... since this is not "part of" pharo, [pharo-users] would be a better place for discussion than [pharo-dev]. > Could you re-announce there, with some description of use cases and who/where the protocol is used? > > cheers -ben > > On Wed, Oct 25, 2017 at 1:42 AM, henry <henry(a)callistohouse.club> wrote: > >> Please excuse all the low-level detail, if inappropriate to the discussion. The protocol changes are here specified. >> >> - HH >> >> On Tue, Oct 24, 2017 at 13:40, henry <henry(a)callistohouse.club> wrote: >> >>> In order to bring ParrotTalk-3.6 support, alongside historical 3.5 support, the frame header stays the same and the processing of the ProtocolOffered would select "ParrotTalk-3.6" to use the compact protocol of >>> >>> - ProtocolOffered { offered, preferred } >>> - ProtocolAccepted { accepted } >>> - IWant|GiveInfo|ReplyInfo { vatId, domain, publicKey, cryptoProtocols, dataEncoders } >>> - IAm|ReplyInfo { vatId, domain, publicKey, cryptoProtocol, dataEncoder, dhParam } >>> - Go { cryptoProtocol, dataEncoder, dhParam, signature } >>> - GoToo { signature } >>> >>> Using eLinda : >>> >>> http://www.squeaksource.com/Cryptography/elinda-HenryHouse.14.mcz >>> >>> Above the FrameBuffer, below the SessionOperations for each version of the protocol, an ELindaSession could be inserted. This session think would have the stacks for each protocol version SessionOperation registered by protocol in a Tuple, for eventual callback. When the ProtocolOffered comes in we publish the tuple frame, with set selected version, to route to the correct SessionOperation to support each version of the protocol. >>> >>> With a non-specific vatId required, anonymous connections would be supported. >>> >>> - HH >>> >>> On Tue, Oct 24, 2017 at 12:52, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >>> >>>> Hi henry thanks for this announce. Can you tell where such protocols are used? Stef On Tue, Oct 24, 2017 at 6:33 PM, henry wrote: > Hi all, > > I am happy to announce the release of version 3.5 of ParrotTalk, for Squeak > and Pharo, found here: > > http://www.squeaksource.com/Cryptography/ParrotTalk-zzz.2.mcz > > It follows this specification: > https://github.com/ZiroZimbarra/callistohouse/blob/master/docs/ParrotTalkFr… > > One item of note, in version 3.5, the system connecting to a server, sending > the IWant msg, must know the vatId of the system being connected to. I am > considering changing this to version 3.6 by removing one round-trip in > messaging. Therefore, these messages would be combined: IWant/GiveInfo, > IAm/ReplyInfo. I will keep ProtocolOffered and ProtocolAccepted to allow > eLindaSession to support both versions: 3.5 and 3.6. > > Thoughts please? > > - HH

Oct. 25, 2017

feenk log

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

Oct. 25, 2017

Re: [Pharo-dev] Bloc Feedback

by Tudor Girba

Hi Sean, > On Oct 25, 2017, at 2:14 PM, Sean P. DeNigris <sean(a)clipperadams.com> 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: >> <http://forum.world.st/file/t128965/Chromium5.png> > > > > > ----- > 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."

Oct. 25, 2017

Re: [Pharo-dev] UnifiedFFI Docs

by Esteban Lorenzano

:) 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> 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> wrote: >> >> Hi, >> >>> On 21 Oct 2017, at 21:15, Stephane Ducasse <stepharo.self(a)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> 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> 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> wrote: >>>> >>>> >>>> >>>> On Thu, Oct 19, 2017 at 1:05 AM, Todd Blanchard <tblanchard(a)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> >>>>> 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> >>>>> 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> >>>>>> wrote: >>>>>>> Wonderful! Thanks. >>>>>>> >>>>>>>> On Oct 17, 2017, at 3:45 PM, stephan <stephan(a)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://github.com/SquareBracketAssociates/Booklet-uFFI >>>>>>>> >>>>>>>> has a link to a bintray pdf download >>>>>>>> >>>>>>>> Stephan >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> >

Oct. 25, 2017

Re: [Pharo-dev] Bloc Feedback

by 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: > <http://forum.world.st/file/t128965/Chromium5.png> ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Oct. 25, 2017

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

by Sven Van Caekenberghe

> On 25 Oct 2017, at 14:02, Sean P. DeNigris <sean(a)clipperadams.com> 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

Oct. 25, 2017