Hi Max, oops, I was being dense...
On Dec 7, 2014, at 5:14 AM, Max Leske <[email protected]> wrote: > >> On 07 Dec 2014, at 04:19, Eliot Miranda <[email protected]> wrote: >> >> Hi Max, > > Hi Eliot, > >> >> On Sat, Dec 6, 2014 at 1:43 AM, Max Leske <[email protected]> wrote: >>> >>>> On 06 Dec 2014, at 04:37, Eliot Miranda <[email protected]> wrote: >>>> >>>> >>>> >>>> On Thu, Dec 4, 2014 at 11:35 PM, Max Leske <[email protected]> wrote: >>>>> >>>>> > On 05 Dec 2014, at 08:02, Norbert Hartl <[email protected]> wrote: >>>>> > >>>>> > >>>>> > >>>>> > >>>>> >> Am 04.12.2014 um 23:31 schrieb Thierry Goubier >>>>> >> <[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? >>>> 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 >
