> On 07 Dec 2014, at 19:24, Eliot Miranda <[email protected]> wrote: > > Hi Max, > > oops, I was being dense... > > On Dec 7, 2014, at 5:14 AM, Max Leske <[email protected] > <mailto:[email protected]>> wrote: > >> >>> On 07 Dec 2014, at 04:19, Eliot Miranda <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hi Max, >> >> Hi Eliot, >> >>> >>> On Sat, Dec 6, 2014 at 1:43 AM, Max Leske <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> On 06 Dec 2014, at 04:37, Eliot Miranda <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> >>>> >>>> On Thu, Dec 4, 2014 at 11:35 PM, Max Leske <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> > On 05 Dec 2014, at 08:02, Norbert Hartl <[email protected] >>>> > <mailto:[email protected]>> wrote: >>>> > >>>> > >>>> > >>>> > >>>> >> Am 04.12.2014 um 23:31 schrieb Thierry Goubier >>>> >> <[email protected] <mailto:[email protected]>>: >>>> >> >>>> >> Hi all, >>>> >> >>>> >> I'm just wondering. >>>> >> >>>> >> Would it work to have a package format based on Fuel? >>>> >> >>>> > I doubt it would work cross platform. I don't know how fuel serializes >>>> > WideString, LargePositiveInteger, BoxedFloat64. These differ between >>>> > smalltalk platforms. The source as string solves that. Strings are >>>> > written as unicode string and numbers as certain number format etc. >>>> >>>> True. Cross dialect loading isn’t something we encourage to do with Fuel. >>>> >>>> @Thierry >>>> You said something about partial loading: that will never be possible with >>>> Fuel because of its pickle format. To select any partial graph you have to >>>> first read the entire file and rebuild the graph first (ok, you don’t >>>> strictly have to build the graph but you still need to read the entire >>>> file). >>>> >>>> Hi Max, you misunderstand what partial loading means in this context. I >>>> designed and implemented partial loading for the Parcel system in VW, and >>>> Fuel is essentially a clean reimplementation of parcels. The idea is that >>>> one does indeed read the entire object graph, but then only the parts of >>>> the graph that mate with the current class hierarchy are installed, and >>>> the bits that don't fit are stored for later. Why? So that a component >>>> can define extensions on classes in components that may not be present. >>>> Why? So that one can maintain a single logical component in a single >>>> package instead of decomposing it into independently loadable fragments. >>> >>> Makes sense. It’s just that I often get asked if it is possible to read / >>> update only parts of a Fuel file, so I wanted to make it clear that that >>> can’t work. >>> >>> Right, good point. But is there a use case? For example, in effect is >>> there a difference between being able to patch a part of a Fuel file and >>> loading that file into an image (possibly automatically), patching the >>> object graph and saving a new version? >> >> Yes, performance seems to be the main use case. Fuel files of hundreds of MB >> take a long time to load and save, even if you only change a single string. >> One instance where this is relevant is the Moose model. They currently use >> .mse files, which use a textual representation (if I’m not mistaken). Usman >> asked me if Fuel were an option, especially for updating only parts of the >> model. > > Ah ok. Then yes, I suspect Fuel will be faster, but that patching is more > complex because it can't be done in a text editor. How do they edit the .mse > file? IME text editors suck on large files. What are the relative > frequencies of writing, reading and editing these files?
I don’t think they can patch the .mse files. That’s exactly why they are looking for alternatives. I have no clue about the read / write frenquencies they need. I’m CC’ing this to Usman, maybe can comment on that. > > >>>> Lets take an example like Fuel itself. This may have specialised >>>> marshalling and unmarshalling extensions defined on may classes, some of >>>> which may be to do with the GUI. If we have partial loading we can load >>>> Fuel into a headless image. The extensions on the GUI classes will simply >>>> not be installed, *until* we load the GUI. Hence Fuel does not have to be >>>> decomposed every time we factor the system into subcomponents. Without >>>> partial loading Fuel must be decomposed into a series of fragments so that >>>> it can load that part that fits into the headless base, and we have to >>>> manage teh dependency to ensure the fragment that loads against the GUI is >>>> loaded when the GUI is loaded. Worse still, if we cut the GUI into two >>>> (e.g. development vs deployment tools) we have to visit the Fuel GUI >>>> component (and potentially many other component) and decompose it into two >>>> pieces. In practice this is extremely costly to maintain, verging on >>>> chaos. With partial loading things are simple. >>>> >>>> Perhaps I should have called it partial installation, but you get the >>>> idea. >>> >>> Thanks for the explanation. >>> >>>> >>>> >>>> > >>>> > Norbert >>>> > >>>> >> Would that make loading faster? >>>> >> >>>> >> Does it already exist? >>>> >> >>>> >> Thanks, >>>> >> >>>> >> Thierry >>>> > >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> best, >>>> Eliot >>> >>> >>> >>> >>> -- >>> best, >>> Eliot
