Re: [Pharo-dev] Fuel materialization on spur

2015-12-17 Thread Robert Withers
Phil, I just posted a new diagram that starts to show the 8th and 9th layers. The specs for events, producers and consumers, bound to named type-structure definitions ("types"), are stored at the meta and injects apps (7) into cloud execution container (8) and into type decoders in layer 5.

Re: [Pharo-dev] Fuel materialization on spur

2015-12-16 Thread Robert Withers
Excuse me: With interfaces I think groovy. With object serialization I think avro. With header encoding I think ASN1DER with dynamic extension, we need variable encoding of statistical objects. With packages I think gradle. this would be powerful, robert On 12/16/2015 01:00 PM, Robert

Re: [Pharo-dev] Fuel materialization on spur

2015-12-16 Thread Robert Withers
Allow me to speak a little on my ideas of a distributed meta layer and control layer in cloud deployments with Squeak/Pharo, hopefully in bounds. A distributed system must have an metadata repsoitory describing the traffic and activity. If you look at deployment, code that works with a type

Re: [Pharo-dev] Fuel materialization on spur

2015-12-16 Thread Robert Withers
I'd like to add that this is a real challenge to existing players in BigData, all of who offer solutions in this exact space. Whoever controls it's specification, controls it's cloud market. My back of the envelope proposal (my apologies for my abrasiveness with this approach) is such: We

Re: [Pharo-dev] Fuel materialization on spur

2015-12-16 Thread p...@highoctane.be
Can you make a more detailed vision (with a picture) about this? As I have a cluster running and am paid to do some stuff with all you list, I can use some time exploring those avenues. Phil On Wed, Dec 16, 2015 at 7:07 PM, Robert Withers wrote: > Excuse me: > >

Re: [Pharo-dev] Fuel materialization on spur

2015-12-16 Thread Robert Withers
I really would love to and I will probably do so to take my mind of the refactoring I am engaged in as I broke my SecureSession code. Note this basically includes a small outside header describing the contents of a FEC encoded msg. There will be an inside header coming later. I am not yet ASN1

Re: [Pharo-dev] Fuel materialization on spur

2015-12-16 Thread Mariano Martinez Peck
Hi guys, I would like to say a couple of things: 1) *Fuel format*: Sven is right in the sense that Fuel has problems of migrating to another Fuel version. However there is some explanation needed here. Previously (years ago), a given Fuel version was not compatible with previous versions

Re: [Pharo-dev] Fuel materialization on spur

2015-12-16 Thread H. Hirzel
It probably should be noted here as well that http://pharo.gemtalksystems.com/book/PharoTools/SIXX/ (Smalltalk Instance eXchange in XML) http://www.mars.dti.ne.jp/~umejava/smalltalk/sixx/index.html allows to transfer data from one image version to another image version / Smalltalk dialect. The

Re: [Pharo-dev] Fuel materialization on spur

2015-12-16 Thread H. Hirzel
No, it is a Smalltalk format. On 12/16/15, Denis Kudriashov wrote: > 2015-12-16 14:41 GMT+01:00 H. Hirzel : > >> It probably should be noted here as well that >> >> http://pharo.gemtalksystems.com/book/PharoTools/SIXX/ >> > > Just to know does java

Re: [Pharo-dev] Fuel materialization on spur

2015-12-16 Thread Denis Kudriashov
2015-12-16 14:41 GMT+01:00 H. Hirzel : > It probably should be noted here as well that > > http://pharo.gemtalksystems.com/book/PharoTools/SIXX/ > Just to know does java implementation exists?

Re: [Pharo-dev] Fuel materialization on spur

2015-12-16 Thread Sven Van Caekenberghe
OK, thanks for the explanation, good to hear it. (But, just nitpicking, it still does not say officially 'you can safely save your data in Fuel format and rest assured that you will always be able to read it back'). (Also, if there are compatibility problems between Pharo versions

Re: [Pharo-dev] Fuel materialization on spur

2015-12-16 Thread H. Hirzel
If you want to move data to Java then you probably go for JSON or a particuar XML format. On 12/16/15, H. Hirzel wrote: > No, it is a Smalltalk format. > > On 12/16/15, Denis Kudriashov wrote: >> 2015-12-16 14:41 GMT+01:00 H. Hirzel

Re: [Pharo-dev] Fuel materialization on spur

2015-12-16 Thread H. Hirzel
Is there a Pharo implementation? https://avro.apache.org/docs/1.2.0/ On 12/16/15, Robert Withers wrote: > Please consider Avro. > > robert > > On 12/16/2015 08:58 AM, H. Hirzel wrote: >> If you want to move data to Java then you probably go for JSON or a >> particuar

Re: [Pharo-dev] Fuel materialization on spur

2015-12-16 Thread Robert Withers
Please consider Avro. robert On 12/16/2015 08:58 AM, H. Hirzel wrote: If you want to move data to Java then you probably go for JSON or a particuar XML format. On 12/16/15, H. Hirzel wrote: No, it is a Smalltalk format. On 12/16/15, Denis Kudriashov

Re: [Pharo-dev] Fuel materialization on spur

2015-12-16 Thread Denis Kudriashov
2015-12-16 14:58 GMT+01:00 H. Hirzel : > If you want to move data to Java then you probably go for JSON or a > particuar XML format. > Of course. Or any other format you can find :) SIXX is XML. And maybe somebody implement it in different languages. I just interesting

Re: [Pharo-dev] Fuel materialization on spur

2015-12-16 Thread Robert Withers
I don't know; I'd be surprised. There are 2 parts: encoding and schema. Fuel would be great for it. It is binary. A Squeak/Pharo port would follow the usual get it to work, work right, work fast! :) It's perfect for BigData as it is the recommended Hadoop storage format. hint...hint..

Re: [Pharo-dev] Fuel materialization on spur

2015-12-16 Thread Sven Van Caekenberghe
> On 16 Dec 2015, at 13:24, Clément Bera wrote: > > I don't know if SqueakV3 - Spur32 support is needed, however, I think it is > really important to be able to serialize and materialize objects between 32 > bits spur images and 64bits spur images. I don't know. Yes

Re: [Pharo-dev] Fuel materialization on spur

2015-12-16 Thread Clément Bera
I don't know if SqueakV3 - Spur32 support is needed, however, I think it is really important to be able to serialize and materialize objects between 32 bits spur images and 64bits spur images. 2015-12-16 10:34 GMT+01:00 Esteban Lorenzano : > Hi, > > On 16 Dec 2015, at 08:21,

Re: [Pharo-dev] Fuel materialization on spur

2015-12-16 Thread Denis Kudriashov
Hi. 2015-12-16 13:33 GMT+01:00 Sven Van Caekenberghe : > > On 16 Dec 2015, at 13:24, Clément Bera wrote: > > > > I don't know if SqueakV3 - Spur32 support is needed, however, I think it > is really important to be able to serialize and materialize objects

Re: [Pharo-dev] Fuel materialization on spur

2015-12-16 Thread Sven Van Caekenberghe
> On 16 Dec 2015, at 13:46, Denis Kudriashov wrote: > > Hi. > > 2015-12-16 13:33 GMT+01:00 Sven Van Caekenberghe : > > On 16 Dec 2015, at 13:24, Clément Bera wrote: > > > > I don't know if SqueakV3 - Spur32 support is needed,

Re: [Pharo-dev] Fuel materialization on spur

2015-12-16 Thread Denis Kudriashov
2015-12-16 13:49 GMT+01:00 Sven Van Caekenberghe : > I might be wrong, but that is how I understood it from discussion in the > past when moving data from one fuel version to another. Will see what they answer. But supporting different versions of Fuel is not same as supporting

Re: [Pharo-dev] Fuel materialization on spur

2015-12-16 Thread Mariano Martinez Peck
On Wed, Dec 16, 2015 at 10:17 AM, Sven Van Caekenberghe wrote: > OK, thanks for the explanation, good to hear it. > > (But, just nitpicking, it still does not say officially 'you can safely > save your data in Fuel format and rest assured that you will always be able > to read it

Re: [Pharo-dev] Fuel materialization on spur

2015-12-16 Thread Robert Withers
Seriously, I think of the I3 work from VW, so CORBA interface schemas are dynamically generated. The same could be done with AVRO schemas, then you could easily read and analyze BigData data, which is pretty happening in the market and still just getting started. Fuel would be a key part of

Re: [Pharo-dev] Fuel materialization on spur

2015-12-16 Thread Esteban Lorenzano
Hi, > On 16 Dec 2015, at 08:21, Eliot Miranda wrote: > > Hi Esteban, > > On Dec 15, 2015, at 5:06 AM, Esteban Lorenzano > wrote: > >> >>> On 15 Dec 2015, at 13:18, Norbert Hartl >>

[Pharo-dev] Fuel materialization on spur

2015-12-15 Thread Norbert Hartl
We have a test build for pharo5 that checks if we need to do stuff for future migrations. Since yesterday it fails, of course. I have a fueled out object graph stored as byte array in a method. The fuel bytes are serialized using a non-spur image. Now when the spur image reads the bytes I get

Re: [Pharo-dev] Fuel materialization on spur

2015-12-15 Thread Robert Withers
On 12/15/2015 07:18 AM, Norbert Hartl wrote: We have a test build for pharo5 that checks if we need to do stuff for future migrations. Since yesterday it fails, of course. I have a fueled out object graph stored as byte array in a method. The fuel bytes are serialized using a non-spur image.

Re: [Pharo-dev] Fuel materialization on spur

2015-12-15 Thread Max Leske
> On 15 Dec 2015, at 14:06, Esteban Lorenzano wrote: > > >> On 15 Dec 2015, at 13:18, Norbert Hartl > > wrote: >> >> We have a test build for pharo5 that checks if we need to do stuff for >> future migrations. Since

Re: [Pharo-dev] Fuel materialization on spur

2015-12-15 Thread Max Leske
Characters are now primitive. There shouldn’t be any need to change Character serialization though. I tried to reproduce your case and I can’t. The only way I can get the primitive to fail is by supplying a negative value. I suspect that the problem happens beforehand, so that the byte being

Re: [Pharo-dev] Fuel materialization on spur

2015-12-15 Thread Esteban Lorenzano
> On 15 Dec 2015, at 13:18, Norbert Hartl wrote: > > We have a test build for pharo5 that checks if we need to do stuff for future > migrations. Since yesterday it fails, of course. > I have a fueled out object graph stored as byte array in a method. The fuel > bytes are

Re: [Pharo-dev] Fuel materialization on spur

2015-12-15 Thread Eliot Miranda
Hi Esteban, > On Dec 15, 2015, at 5:06 AM, Esteban Lorenzano wrote: > > >> On 15 Dec 2015, at 13:18, Norbert Hartl wrote: >> >> We have a test build for pharo5 that checks if we need to do stuff for >> future migrations. Since yesterday it fails, of