- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Object graph stream/visitor implementation?

by Marcus Denker

> On 22 Dec 2015, at 09:46, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hello. > > Do we have way to traverse object graph? > > I want stream which iterate object graph through instance variables with knowledge about path at every step. > > Maybe Fuel has classes for this ? > yes, I think so.. there is #fuelAccept:, but I am not sure how general it is. I remember that Doru did some object graph iteration experiments, too? (I canât find it). But I think we should actually add a general âobject graph iteratorâ to the reflective features of the language. It seems very useful to have, and for sure Fuel could just use it. Marcus

Dec. 22, 2015

Re: [Pharo-dev] Object graph stream/visitor implementation?

by Robert Withers

I managed to get per object substitution callbacks working in Mushroom. Please take a look in http://www.squeaksource.com/Mushroom and load Mushr00m-Pharo on top of MushrOOm (after installing Cryptography and SecureSession from http://www.squeaksource.com/Cryptography) Then look at the classes in the Utility category. HTH, Robert On 12/22/2015 03:46 AM, Denis Kudriashov wrote: > Hello. > > Do we have way to traverse object graph? > > I want stream which iterate object graph through instance variables > with knowledge about path at every step. > > Maybe Fuel has classes for this ? > > Best regards, > Denis -- . .. ... ^,^ robert Go Panthers!

Dec. 22, 2015

Object graph stream/visitor implementation?

by Denis Kudriashov

Hello. Do we have way to traverse object graph? I want stream which iterate object graph through instance variables with knowledge about path at every step. Maybe Fuel has classes for this ? Best regards, Denis

Dec. 22, 2015

Any thread-safe collection for Pharo?

by Denis Kudriashov

Hello. Anybody know thread-safe collections project?

Dec. 22, 2015

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Consortium Sponsored Development Effort

by Ben Coman

On Tue, Dec 22, 2015 at 3:20 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Sun, Dec 20, 2015 at 5:21 PM, Thierry Goubier <thierry.goubier(a)gmail.com> > wrote: >> >> Hi Mariano, >> >> Le 20/12/2015 19:54, Mariano Martinez Peck a Ã©crit : >>> >>> Hi Dimitri, Dave et all. >>> >>> First let me do a little disclaimer. Regarding the developments itself >>> of this sponsorship, we discussed about the topics I said in the first >>> email. However, those are not written in stone and that's why I also >>> asked for feedback. As you know, Pharo has relatively little resources >>> so those should be well spent. If we decide to take a spin into a >>> project X, it doesn't mean other projects are not worth. It simply means >>> that we think X will be the most useful for the time being. >>> >>> One of the final goals of the discusses topics, is to improve a bit the >>> infrastructure for using Pharo as scripting (imagine Coral). For such a >>> thing, we believe that improving FileSystem and OSProcess-like is a good >>> first step to improve the underlying infrastructure. >> >> >> Would we have access then to a command-line oriented minimal Pharo image? >> > > Well, just for putting perspective my sponsorship is about 3 full months of > work effort. It doesn't mean I won't work beyond that. But to give you an > idea. I think we all want minimal images , command line etc. And Pharo has > already done a huge effort in that direction. >>> >>> That being said, I of course like the idea of distributing processing >>> across multiple images. No wonder, my PhD tool (Marea) and related >>> sub-projects (Fuel, Ghost proxies, etc) have something to do with the >>> mentioned topic. Dave already mentioned about RemoteTask, which was >>> something I was about to mention. There is also Seamless project (now >>> used by Remote Debugger stuff) and quite other tools. Finally, I think >>> this project may have a big percentage that could be considered as >>> "research". So having a PhD / master student working on this would also >>> be nice. In fact, maybe Denis Kudriashov might work on that topic??? (he >>> is now in RMOD team). >>> >>> Also, not that forking the image is not my main short-term goal. As >>> said, I will experiment first with a simple tool to execute OS commands >>> that would be FFI based, trying to make async operations, and that would >>> help in most cases. Maybe for those that are not supported, then >>> fallback in OSProcess. Note that Dave (OSProcess author) is very helpful >>> with me and we are discussing together about this. >> >> >> My guess is that, at least on Linux/Unix, that FFI will be exactly the >> same as the one used/expressed by the OSProcess plugin, that is >> popen/system. > > > No, wait. You are getting down to the details so I want to discuss :) > > OSProcess does not use popen()/system() but rather fork()+exec(). That means > that OSProcess has implementing the very very low building blocks that would > allow you do to almost everything. But then it has it's complicated matters. > fork() + exec() cannot be implemented via FFI (this was already discussed in > another thread). Can you link that thread? I'm curious to learn this. Is it multi-thread related? I read [a]... ..."The biggest problem with using fork+exec in this way is that you can't guarantee *nothing* happens between the fork call and the exec call. If, for example, the JVM decides to GC or move memory around, you can have a fatal crash at the JVM process level. Because of that, I don't recommend using fork + exec via FFI in JRuby, even though it's pretty cool. " ..."However, since this post I've learned of the "posix_spawn" [b] function available on most Unix variants. It's basically fork + exec in a single function, plus most of the typical security and IO tweaks you might do after forking and before execing. It's definitely my recommended alternative to fork+exec for JRuby." And posix_spawn also seems recommended for use with the JVM [d] and that Windows and POSIX might have similar usage, and even better match Windows CreateProcess than fork/exec [f] [g] [h] And since with 64-bit Spur we can expect very large images, spawn may be preferred over fork/exec to minimize memory usage for creating application subprocesses [i] Fork versus threads section of [c] or should we be making use of pthread_atfork [e] ? Overall I learnt something new about forking in a multi-threaded environment "When fork() is called, only the calling thread is duplicated in the child process." [a] http://blog.headius.com/2009/05/fork-and-exec-on-jvm-jruby-to-rescue.html [b] http://pubs.opengroup.org/onlinepubs/009695399/functions/posix_spawn.html [d] http://skife.org/java/2012/01/24/java_daemonization_with_gressil.html [c] http://repository.readscheme.org/ftp/papers/sw2002/gasbichler.pdf [e] http://stackoverflow.com/questions/4223553/c-does-exec-have-to-immediately-… [f] http://stackoverflow.com/questions/33249253/what-is-the-difference-between-… [g] http://stackoverflow.com/questions/5883462/linux-createprocess [h] http://www.linuxquestions.org/questions/programming-9/fork-exec-versus-posi… [i] http://www.oracle.com/technetwork/server-storage/solaris10/subprocess-13643… > However, there is a lot of other stuff that we believe it > could. So... what we wanted to see if it is possible is to have one only (or > very few) primitives (like forkAndExec) and all the rest via FFI. And then > all the features I listed in the first email of this thread. > > With that in mind, we believe that: > > 1) Before starting dealing with forkAndExec, we could try a first prototype > using popen(). That would allow us test a 100% FFI based approeach, deal > with writing and reading from pipes via stream, face the blocking issue, see > a prototype on how to read async from pipes etc etc etc. If we see this > works nicely, on a second step we can build another approach that instead of > popen() uses forkAndExec primitive. Is popen() being restricted to unidirectional part of this consideration [j] ? Also I read [j] that a problem with popen is that you do not get pid of child so you cannot wait on command to complete. Could posix_spawn be preferrable to popen? and just btw, mildly interesting is using sockets rather than pipes for interprocess communication [l] [j] http://stackoverflow.com/questions/3884103/can-popen-make-bidirectional-pip… [k] http://stackoverflow.com/questions/6743771/popen-alternative [l] http://stackoverflow.com/questions/25161377/open-a-cmd-program-with-full-fu… > > 2) We believe that there is a large number of OSProcess users that use > OSProcess only for executing OS commands AND popen() approach would be more > than enough (we will do a survey about this). So, a very simply solution via > FFI for these users rather than having all OSProcess, Command Shell, the > plugins etc, may be worth. > > What do you think? > >> >> Now, given some of the difficulties seen when dealing with external >> processes, I'd be wary of the "async" side of things. Random failures >> seemingly linked to signal loss are certainly not something I'd like to >> debug. >> > > Indeed, it won't be easy I guess. But sometimes the process you execute may > take quite some time and blocking the VM for that period is not a good > choice. So... what would you prefer to solve that? Do you prefer image-based > pooling as OSProcess does when IOPlugin is not used? How much might your work overlap with the Threaded FFI project for Cog?... ..."The Cog VM is single-threaded, providing green threads to the Smalltalk level, as do most Smalltalk VMs. There is a prototype subclass of the CoInterpreter, CoInterpreterMT, which provides a Python-like multi-threaded VM where any number of threads can share the VM with only one running the VM at any one time. This uses an extremely simple low-level scheme for releasing and re-acquiring ownership of the VM designed by David Simmons. This results in any and all FFI calls being non-blocking since there is such a low overhead to making a non-blocking FFI call that all FFI calls can be non-blocking. Eliot has worked on this, implementing the prototype and the reentrant FFI plugin it requires. But this needs to be revived. It would be a really powerful enhancement." cheers -ben P.S. Just another article warning against mixing fork and multiple-threads (which it seems posix_spawn may avoid)... http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-usi…

Dec. 22, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers: (Max Leske)

by Max Leske

Thanks for your opinion Richard. Without going into detail about your answer I just want to add something to the discussion that I feel has gone unsaid: #inject:into: is hard to understand. I *love* #inject:into:. But it took me a long time before I understood how it really works. Pharo has the goal, beside others, to make entry for new users easy. A nice implementation of #sum that shows how #inject:into: works is one way of doing that IMHO and it allows new users to *use* the language without having to understand methods like #inject:into: Just my five cents. And donât get me wrong, I absolutely second the thought that we should at least ask ourselves if methods like #sum should be implemented on Collection. Cheers, Max > On 22 Dec 2015, at 00:14, Richard Uttner <richard.uttner(a)gmail.com> wrote: > > > 2015-12-21 23:48 GMT+01:00 Richard Uttner <richard.uttner(a)gmail.com <mailto:richard.uttner@gmail.com>>: > This is my first contribution to the DevList and I hope you forgive me that it sounds more like "I see something we dont need" than the other way round, but there will be more positive posts of mine concering the Unicode debate (which I will postpone to the New Year in order to be able to respond quickly). > From a developer's point of view that is dealing with more than one environment (3 Smalltalk environments including Pharo, where I am a newby) and a handful of other languages, I dont like to reuse interfaces that are hard to remember and understand though the task done by them is so easy that I can write it down in one simple #inject:into-line 10 times faster than looking it up in the implementors browser. Furthermore, something like #inject:into: will work forever and never be deprecated! Fullstop. > Next thing that is easily overlooked is the semantics. I am not that good in mathematics, but I would suppose that summing up does by definition not need a neutral element - only an implementation that can be written down in 2 lines needs it. A mathematically correct implementation of summing up anything (including nil ... see reason below) that implements #+ would be: > > Collection:>>#sum > | undef result | > undef := result := Object new. > self do: [:each | result := result == undef ifTrue: [each] ifFalse: [result + each]]. > > > "(Sorry for the incomplete mail .... Gmail in Browser apparently has a keyboard shortcut for sending the mail if caret key is pressed along with spaces ...weird ... :() > Continuing with missing return statement for above:" > ^result > > (Why I am using "Object new" instead of nil: I would not recommend implementing #+ in nil, but not prohibit it in a general interface, if somebody needs it in an own extension. Thus relying on nil would spoil this theoretical possibility unnecessarily.) > > The reasons for writing it down like above are: > - no sideeffects with possibile overflows (think of a collection containing one element near maxval that is added twice like in the other proposed solutions, and then subtracted finally) > - no need to implement #- in special classes that are no numbers but want to use #sum > - no need for a neutral element > > Main disadvantage of my proposed implementation is the fact that we hardly can distinguish a valid result from an invalid one if we dont use nil. What I think is the main reason for all argueing around this interface is simply: Though it sounds reasonable to define something like #sum for Collection at first sight, in fact its semantics is too blurry - we need to pass the desired result in order to reasonably handle empty collections. For most practicable application cases, this can be done instead by simply injecting 0. So please avoid so many new methods that developers have to study in order to understand their respective limit conditions (and primitives are even worse - how will coercing be done if the result gets large? Will it fail on Fraction elements? ...?) > > So my personal summary is: No implementation of #sum - variants in Collection due to vague semantics and no real advantage against directly using #inject:into. > > Best regards, > Richard > > 2015-12-21 18:00 GMT+01:00 <pharo-dev-request(a)lists.pharo.org <mailto:pharo-dev-request@lists.pharo.org>>: > Send Pharo-dev mailing list submissions to > pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.org <http://lists.pharo.org/mailman/listinfo/pharo-dev_lists.pharo.org> > or, via email, send a message with subject or body 'help' to > pharo-dev-request(a)lists.pharo.org <mailto:pharo-dev-request@lists.pharo.org> > > You can reach the person managing the list at > pharo-dev-owner(a)lists.pharo.org <mailto:pharo-dev-owner@lists.pharo.org> > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pharo-dev digest..." > > > Today's Topics: > > 1. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored > Development Effort (Dimitris Chloupis) > 2. Re: #sum:, #detectSum:, #sumNumbers: (Max Leske) > 3. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored > Development Effort (Mariano Martinez Peck) > 4. Re: #sum:, #detectSum:, #sumNumbers: (Max Leske) > 5. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored > Development Effort (Dimitris Chloupis) > 6. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored > Development Effort (Thierry Goubier) > 7. Re: #sum:, #detectSum:, #sumNumbers: (Tudor Girba) > 8. [pharo-project/pharo-core] (GitHub) > 9. [pharo-project/pharo-core] e8216b: 50508 (GitHub) > 10. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored > Development Effort (Denis Kudriashov) > 11. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored > Development Effort (Ben Coman) > 12. Re: [squeak-dev] [Unicode] Summary (Re: Unicode Support // e > acute example --> decomposition in Pharo?) (Sven Van Caekenberghe) > 13. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored > Development Effort (Thierry Goubier) > 14. Re: [squeak-dev] [Unicode] Summary (Re: Unicode Support // e > acute example --> decomposition in Pharo?) (Sven Van Caekenberghe) > 15. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored > Development Effort (Robert Withers) > 16. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored > Development Effort (phil(a)highoctane.be <mailto:phil@highoctane.be>) > 17. Re: [ANN] Multiple Desktop support for Pharo 5 (H. Hirzel) > 18. No refactoring for equal/hash generation (Denis Kudriashov) > 19. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored > Development Effort (Denis Kudriashov) > 20. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored > Development Effort (Mariano Martinez Peck) > 21. Re: [Pharo-users] [ANN] Pharo Consortium Sponsored > Development Effort (Robert Withers) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 20 Dec 2015 17:17:42 +0000 > From: Dimitris Chloupis <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> > To: Pharo Development List <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>> > Subject: Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Consortium > Sponsored Development Effort > Message-ID: > <CAN88a2F3CNMTZRbdHttwmHzzsxKgs5qZUj%3DuBE4UAM4tAVZcrA(a)mail.gmail.com <mailto:uBE4UAM4tAVZcrA@mail.gmail.com>> > Content-Type: text/plain; charset="utf-8" > > how the communication is happening via Fuel , does it save to a fuel file > or it does it through memory some way ? > > On Sun, Dec 20, 2015 at 6:04 PM David T. Lewis <lewis(a)mail.msen.com <mailto:lewis@mail.msen.com>> wrote: > > > On Sun, Dec 20, 2015 at 05:07:47PM +0800, Pierce Ng wrote: > > > On Sun, Dec 20, 2015 at 08:56:43AM +0000, Dimitris Chloupis wrote: > > > > Fuel I assume enters here the equation as a data exchange format , the > > > > problem I have with fuel is that its not backward compatible which for > > me > > > > > > > Fuel works well in this case. Version compatibility is not an issue, > > because > > when you fork an image/VM the two cooperating images are essentially > > identical. > > > > > Once you have a set of OS processes running Pharo how they talk to each > > other > > > is up to you no? E.g. the Pharo instances could use ZeroMQ, XML-RPC, > > JSONRPC, > > > msgpack, coordinate via Redis/SQLite/PostgreSQL, etc. > > > > Any of those would work, but Fuel is a good way to enable all kinds of > > objects to be copied from one image to another through a stream. In the > > case of RemoteTask, all of the results of a remote computation can be put > > into a single result object (an array or a dictionary or whatever), and > > that result can be passed back to the parent image by reading the single > > object. So - fork a copy of the image, have it do some work, and read the > > result object from a stream. You know you are done when you have read > > exactly one object. > > > > Dave > > > > >

Dec. 22, 2015

Refinements.. Re: SecureSession protocol version 1.0 ( was Re: [Vm-dev] Re: SecureSession frame types)

by Robert Withers

I call these evolutions refinements. A few more here, pardon the bandwidth: `1 - It was unspecified but the 4 tag bits can have 16 values, 1 for this protocol. The availability of 15 other protocols is a feature for open-source development. `2 - a header is easily defined for different transports and networks. `3 - the header of a FEC message is separately FEC encoded and interleaved with RS(15,9), so 30 bytes for the msgSpec and header, followed by the rsMode specified FEC encoding of the payload, padded out from msgSize. thank you, robert On 12/21/2015 08:42 PM, Robert Withers wrote: > I updated with all the feedback and here is a version 1.0 pdf > specification. I appreciate any comments or suggestions you may have > for this. > > https://www.dropbox.com/s/ywu9pjxrfvg1hys/FrameTypes.pdf?dl=0 > > > Thank you, > Robert > > On 12/20/2015 10:51 AM, Robert Withers wrote: >> More, sorry. I left out the msgSize in the FEC spec. Let me reorder >> the tagging, fit the 3 bytes of normal msgSpec into 4bytes and thusly... >> >> >> ---Default non-FEC msgSpec + header + payload layout: >> >> - 8bytes (X) messageSpecification... >> - >> - (32bits...) >> - 4bits tagging >> - 6bits multicastSymbol >> - 6bits messageVersion >> - 2bits sanguinity >> - 6bits headerType "Implies Y header size. NOTE: except for FEC >> encodings" >> - 8bits unused >> - (32bits...) >> - 4bytes messageSize (X+Y+Z) (Z bytes = (messageSize - headerSize(Y) >> - 8bytes msgSpec (X = 8)) >> - >> - Ybytes message header >> https://www.dropbox.com/s/ywu9pjxrfvg1hys/FrameTypes.pdf?dl=0 >> - >> - Zbytes message payload >> >> >> >> Special FEC coded 64bit <msgSpec + header> + payload layout, for >> 64bit alignment: >> >> - 8bytes (X) message specification... >> - >> - (32bits...) >> - 4bits tagging >> - 6bits multicastSymbol >> - 6bits messageVersion >> - 2bits sanguinity >> - 6bits FEC message type "NOTE: this means different layout" >> - 2bits rsMode >> - 6bits partial blockCount >> - (32bits...) >> - 4bits blockCount "NOTE: for 1MB encoded/982KB data - >> blockCount * blockCodeBytes = Z" >> - 20bits messageSize (X+Y+Z) (Z bytes = (messageSize - headerSize(Y) >> - 8bytes msgSpec (X = 8)) "NOTE: this can specify 1MB data" >> - 8bits primitivePolynomial spec (good for our current rsModes) >> - >> - Y = 0 >> - >> - Zbytes-sized payload >> >> Ok, that's what it is I think, this proposal. >> >> robert >> >> >> >> On 12/20/2015 10:33 AM, Robert Withers wrote: >>> ---Default non-FEC msgSpec + header + payload layout: >>> >>> - 6bits multicastSymbol >>> - 2bits sanguinity >>> - 6bits messageVersion >>> - 6bits headerType "NOTE: except for FEC encodings" >>> - 4bytes messageSize >>> - Xbytes header >>> - >>> - (messageSized - headerSize - 7specBytes) Bytes-sized payload >>> >>> >>> Special FEC coded 64bit <msgSpec + header> + payload layout, for >>> 64bit alignment: >>> >>> - (32bits...) >>> - 6bits multicastSymbol >>> - 2bits sanguinity >>> - 6bits messageVersion >>> - 6bits FEC message type "NOTE: this means different layout" >>> - 2bits rsMode >>> - (32bits...) >>> - 10bits blockCount "NOTE: for 1MB encoded/982KB data" >>> - 20bits messageSize "NOTE: this can specify 1MB data plus >>> - 8bits primitivePolynomial spec (good for our current rsModes) >>> - 4bits tagging >>> - >>> - (messageSized - headerSize - 4specBytes) OR (blockCount * rsMode's >>> blockCodeBytes) Bytes-sized payload >> > > -- > . .. ... ^,^ robert > Go Panthers! -- . .. ... ^,^ robert Go Panthers!

Dec. 22, 2015

Re: [Pharo-dev] #sum:, #detectSum:, #sumNumbers:

by Ben Coman

On Wed, Dec 2, 2015 at 3:38 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > I am saying that if you want sum: to be generic, it cannot assume a *specific* Zero object. > And sum: should be generic because of its name. This seems the crux of the disparate viewpoints, which is why I suggested return a *generic* Zero object as follows... > On 04 Dec 2015, at 01:49, Ben Coman <btc(a)openInWorld.com> wrote: > do something like... > > Collection>>sum > | sum sample | > self isEmpty ifTrue: [ ^ ArithmeticZero ]. > sample := self anyOne. > sum := self inject: sample into: [ :accum :each | accum + each ]. > ^ sum - sample On Sat, Dec 5, 2015 at 3:12 AM, Max Leske <maxleske(a)gmail.com> wrote: > While I think you might be on to something, I think we should take small > steps. Iâd be happy already if we can just get rid of one superfluous method > and provide a better API without starting to think about the deeper > semantics. Sure, small steps are better, except when this hits a sticking point that the bigger step may overcome. I think returning a generic zero allowing the program to proceed is better than throwing an generic error that the programmer needs to explicitly deal with. The concept of zero is well defined for the common arithmetic functions. Just for a thought experiment, what arithmetic functions would need to be dealt with. > ArithmeticZero class >> + anObject > ^anObject AritmeticZero class >> * anObject ^ anObject zero AritmeticZero class >> - anObject ^ anObject zero - anObject > Also, I think thereâs a reason why Aconcagua is an external package: > developers usually are happy to work with numbers (which are already objects > in Smalltalk anyway) and theyâre fast. Sure its an external package, but when you have a collection of weight readings for example, you want to use the internal convenient #sum method... { 4 kg . 5 kg . 6 kg } sum --> 16kg { } sum + 1 kg --> 1kg { } sum * 1 kg --> 0 kg^2 "hmmm, zero with units and multiplication starts getting more complicated - maybe should be left out of this discussion" > While #sumNumbers may *technically* be the best name (which > we canât seem to agree onâ¦), #sum, #sum: and #sum:ifEmpty: > form a triple that naturally fits into the naming protocol applied > elsewhere. So maybe alternative naming of the generic zero... #sum (empty --> EmptyAggregateZero) #sum: (empty --> EmptyAggregateZero) #sum: ifEmpty: (empty --> whatever) > On Mon, Dec 21, 2015 at 12:43 AM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > Doru, > > For me this whole discussion started because you (the standpoint that you > take) hijacked the best selector (#sum) for a use case that is much less > common than adding a collection of numbers which should give 0 when empty > (you hijack it by not wanting to return 0, which I totally understand, but > doing so you redefine the meaning/semantics). > > Max's point is to make everything more consistent and remove some API. I > support that too. > > Now, I like Max's proposal. > > But, you know, my conclusion when the thread ended was that it might be > better to throw all these selectors away, since #inject:into: covers most > use cases at least as well and at least as clear. #sum is very convenient and that lowers the barrier of entry for newcomers over the relatively exotic #inject:into: We should keep trying to work through the sticky points, but maybe you guys getting together IRL is better than continuing on the mail list. cheers -ben

Dec. 22, 2015

SecureSession protocol version 1.0 ( was Re: [Vm-dev] Re: SecureSession frame types)

by Robert Withers

I updated with all the feedback and here is a version 1.0 pdf specification. I appreciate any comments or suggestions you may have for this. https://www.dropbox.com/s/ywu9pjxrfvg1hys/FrameTypes.pdf?dl=0 Thank you, Robert On 12/20/2015 10:51 AM, Robert Withers wrote: > More, sorry. I left out the msgSize in the FEC spec. Let me reorder > the tagging, fit the 3 bytes of normal msgSpec into 4bytes and thusly... > > > ---Default non-FEC msgSpec + header + payload layout: > > - 8bytes (X) messageSpecification... > - > - (32bits...) > - 4bits tagging > - 6bits multicastSymbol > - 6bits messageVersion > - 2bits sanguinity > - 6bits headerType "Implies Y header size. NOTE: except for FEC > encodings" > - 8bits unused > - (32bits...) > - 4bytes messageSize (X+Y+Z) (Z bytes = (messageSize - headerSize(Y) - > 8bytes msgSpec (X = 8)) > - > - Ybytes message header > https://www.dropbox.com/s/ywu9pjxrfvg1hys/FrameTypes.pdf?dl=0 > - > - Zbytes message payload > > > > Special FEC coded 64bit <msgSpec + header> + payload layout, for 64bit > alignment: > > - 8bytes (X) message specification... > - > - (32bits...) > - 4bits tagging > - 6bits multicastSymbol > - 6bits messageVersion > - 2bits sanguinity > - 6bits FEC message type "NOTE: this means different layout" > - 2bits rsMode > - 6bits partial blockCount > - (32bits...) > - 4bits blockCount "NOTE: for 1MB encoded/982KB data - > blockCount * blockCodeBytes = Z" > - 20bits messageSize (X+Y+Z) (Z bytes = (messageSize - headerSize(Y) - > 8bytes msgSpec (X = 8)) "NOTE: this can specify 1MB data" > - 8bits primitivePolynomial spec (good for our current rsModes) > - > - Y = 0 > - > - Zbytes-sized payload > > Ok, that's what it is I think, this proposal. > > robert > > > > On 12/20/2015 10:33 AM, Robert Withers wrote: >> ---Default non-FEC msgSpec + header + payload layout: >> >> - 6bits multicastSymbol >> - 2bits sanguinity >> - 6bits messageVersion >> - 6bits headerType "NOTE: except for FEC encodings" >> - 4bytes messageSize >> - Xbytes header >> - >> - (messageSized - headerSize - 7specBytes) Bytes-sized payload >> >> >> Special FEC coded 64bit <msgSpec + header> + payload layout, for >> 64bit alignment: >> >> - (32bits...) >> - 6bits multicastSymbol >> - 2bits sanguinity >> - 6bits messageVersion >> - 6bits FEC message type "NOTE: this means different layout" >> - 2bits rsMode >> - (32bits...) >> - 10bits blockCount "NOTE: for 1MB encoded/982KB data" >> - 20bits messageSize "NOTE: this can specify 1MB data plus >> - 8bits primitivePolynomial spec (good for our current rsModes) >> - 4bits tagging >> - >> - (messageSized - headerSize - 4specBytes) OR (blockCount * rsMode's >> blockCodeBytes) Bytes-sized payload > -- . .. ... ^,^ robert Go Panthers!

Dec. 22, 2015

Re: [Pharo-dev] Ephemerons

by Esteban A. Maringolo

2015-12-21 19:14 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> On 21 Dec 2015, at 22:13, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> you will have them with Pharo 5 > and spur, of courseâ¦ but pharo 5 will have them, not previous versions :) Good news for GLORP Weak Cache implementation :) Is it already available in the current Pharo 5 image builds? Regards!

Dec. 21, 2015