Hey it's me again ;-) There are at least two files that are not AL2 licensed but can be used (I think).
https://github.com/noctarius/Lightning/tree/master/lightning-core/src/main/java/com/github/lightning/internal/instantiator/jrockit If it's not possible to leave them in the sourcetree I'm pretty sure there will be no problem when we remove them since they are used for older JRocket versions. Am 29.09.2012 21:05, schrieb Raffaele P. Guidi: > I kinda suspected that... > Il giorno 29/set/2012 20:47, "Noctarius" <[email protected]> ha scritto: > >> Actually all dependencies should be AL2 or BSD licensed :-) >> >> Am 29.09.2012 20:42, schrieb Raffaele P. Guidi: >>>>> Hehe well that really sounds like a nice bunch of people. >>> >>> Indeed they are (I'm a newbie as well and try to do my best) >>> >>>>> If lightning will be a sub-part (sub-project) of DM, do I >>>>> need to write >>> an project purposal? >>> >>> Nope, not needed for a sub-project >>> >>>>> Do I need to make any changes to the pom.xml like adding a >>> special parent pom or anything like that? >>> >>> Not for the serializer - just have to take a look at project >>> dependencies - or, better, at their licenses - are they >>> compatible with the ASL 2.0? i.e. a GPL'd library is not a good >>> fit and should be replaced with an apache licensed (or BSD, or >>> MIT...) one if possible. For the integration module is a >>> separate story - you should start off copying one of the other >>> serializers and reusing the same pom and directory structure. >>> >>> Pleased to meet you, Chris :) >>> >>> Ciao, R >>> >>> On Sat, Sep 29, 2012 at 8:24 PM, Noctarius <[email protected]> >>> wrote: >>> >>>> Hehe well that really sounds like a nice bunch of people. >>>> >>>> Ok to be true I couldn't wait until tomorrow and started >>>> already reading the links. From what I was reading: If >>>> lightning will be a sub-part (sub-project) of DM, do I need >>>> to write an project purposal? >>>> >>>> Do I need to make any changes to the pom.xml like adding a >>>> special parent pom or anything like that? >>>> >>>> In general: there are a lot things to know :-) >>>> >>>> Am 29.09.2012 19:59, schrieb Raffaele P. Guidi: >>>>> Negative part of ASF membership? You get together with a >>>>> lot of geeky, talented people with a fixation for software >>>>> and open source. Oh wait but this is actually nice! :-D Il >>>>> giorno 29/set/2012 19:05, "Olivier Lamy" <[email protected]> >>>>> ha >>>> scritto: >>>>> >>>>>> 2012/9/29 Noctarius <[email protected]>: >>>>>>> Thanks Olivier for carify, I'll take a look in it >>>>>>> tomorrow but there's just one question left (for now >>>>>>> ;)): What is that vote for becoming a committer? What >>>>>>> if the vote will be negative? >>>>>> The vote is on private list (pmc list for privacy reasons >>>>>> and possible negative stuff being on public lists) >>>>>>> Until now I just used Apache stuff, was never >>>>>>> interested in being part of it so I guess it can be >>>>>>> negative for any reason, can't it? >>>>>> I don't see why it could be negative but suspens .... >>>>>> :-) >>>>>>> >>>>>>> Am 29.09.2012 18:56, schrieb Olivier Lamy: >>>>>>>> 2012/9/29 Noctarius <[email protected]>: >>>>>>>>> Nope my real name is Christoph Engelbert, but >>>>>>>>> Noctarius is the all time nick :) >>>>>>>>> >>>>>>>>> Renaming the package should be no problem, is it >>>>>>>>> "org.apache.directmemory.lightning" or what would >>>>>>>>> it be? >>>>>>>> fine for me >>>>>>>>> Then there needs to be a change in the license >>>>>>>>> header as Olivier mentioned, that means just remove >>>>>>>>> the first sentence or is there anything more to do >>>>>>>>> (maybe it's easiest thing to just copy the header >>>>>>>>> from DM file ;))? >>>>>>>> yup use same header as DM >>>>>>>>> >>>>>>>>> The CLA is just a form to clarify that the source >>>>>>>>> can be contributed to the Apache Foundation? >>>>>>>> yup correct. >>>>>>>>> >>>>>>>>> The final step will be attaching the patch in form >>>>>>>>> of a huge diff file? >>>>>>>> yes >>>>>>>>> >>>>>>>>> And what is the way to apply for a membership? >>>>>>>>> Never thought about how to do that. >>>>>>>> Read here >>>>>>>> http://apache.org/foundation/how-it-works.html and >>>>>>>> here http://apache.org/foundation/getinvolved.html . >>>>>>>> And feel free to ask any questions :-) >>>>>>>>> >>>>>>>>> Chris >>>>>>>>> >>>>>>>>> Am 29.09.2012 18:23, schrieb Raffaele P. Guidi: >>>>>>>>>> OK, deal, at least for me ;-) I propose you >>>>>>>>>> rename the packages, produce a patch for this and >>>>>>>>>> the new serializer module (should be simple >>>>>>>>>> enough starting from an existing one) and, in the >>>>>>>>>> meanwhile, apply for ASF membership. Is IP >>>>>>>>>> clearance needed? I guess yes. After this we will >>>>>>>>>> come up with a formal vote regarding Noctarius >>>>>>>>>> (is this your real name?!) allowance in the >>>>>>>>>> project team. >>>>>>>>>> >>>>>>>>>> Good times are gonna come :-) >>>>>>>>>> >>>>>>>>>> Thanks, R Il giorno 29/set/2012 17:58, "Olivier >>>>>>>>>> Lamy" <[email protected]> ha scritto: >>>>>>>>>> >>>>>>>>>>> 2012/9/29 Raffaele P. Guidi >>>>>>>>>>> <[email protected]>: >>>>>>>>>>>> Well we already have a NIO ready interface >>>>>>>>>>>> allowing direct access to DMs managed >>>>>>>>>>>> bytebuffers but I think this is just half way >>>>>>>>>>>> to what could be achieved optimally blending >>>>>>>>>>>> serialization and memory allocation >>>>>>>>>>>> together. >>>>>>>>>>>> >>>>>>>>>>>> Lightning as a module is of course a good >>>>>>>>>>>> idea and it could easily evolve as a >>>>>>>>>>>> subproject (for the more experienced asf >>>>>>>>>>>> members: is it a feasible way?). >>>>>>>>>>> Nothing prevent to have >>>>>>>>>>> http://svn.apache.org/repos/asf/directmemory/lightning/trunk >>>>>>>>>>> >>>>>>>>>>> >>>>>>> >>>>>>>>>>> >> with a package like: o.a.d.lightning That will be a >>>>>>>>>>> subproject. >>>>>>>>>>>> >>>>>>>>>>>> Ciao, R Il giorno 29/set/2012 17:44, >>>>>>>>>>>> "Noctarius" <[email protected]> ha scritto: >>>>>>>>>>>> >>>>>>>>>>>>> Hey guys, >>>>>>>>>>>>> >>>>>>>>>>>>> ok there's no lightning binary available >>>>>>>>>>>>> since lightning wasn't ready yet for >>>>>>>>>>>>> releasing. >>>>>>>>>>>>> >>>>>>>>>>>>> For being the only developer it would be no >>>>>>>>>>>>> problem to contribute the sourcebase for >>>>>>>>>>>>> DirectMemory but I'm not sure yet if it >>>>>>>>>>>>> wouldn't be better to seperate it to be >>>>>>>>>>>>> available without using DirectMemory >>>>>>>>>>>>> itself. I started it as a serializer for >>>>>>>>>>>>> cluster synchronization, but it would be >>>>>>>>>>>>> cool to contribute lightning as a >>>>>>>>>>>>> subproject to DirectMemory :-) >>>>>>>>>>>>> >>>>>>>>>>>>> About the second project I would love to >>>>>>>>>>>>> see a public available buffer API directly >>>>>>>>>>>>> in DirectMemory so that project would be >>>>>>>>>>>>> nearly needless :-) The only difference I >>>>>>>>>>>>> think is the allocation strategy my >>>>>>>>>>>>> implementation is using against the one >>>>>>>>>>>>> DirectMemory has, but I'm pretty sure the >>>>>>>>>>>>> allocation is extensible ;-) >>>>>>>>>>>>> >>>>>>>>>>>>> Like I said, for both projects I'm the only >>>>>>>>>>>>> dev so there would be no IP problem. So if >>>>>>>>>>>>> it's ok to you to not include lightning >>>>>>>>>>>>> directly in DM I would be glad to >>>>>>>>>>>>> contribute to the Apache Foundation :-) >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers Chris >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Am 29.09.2012 16:53, schrieb Raffaele P. >>>>>>>>>>>>> Guidi: >>>>>>>>>>>>>> Ok so it's up to noctarius - your move! >>>>>>>>>>>>>> ;-) Regarding the new unsafe storage: >>>>>>>>>>>>>> it's an opt-in feature that can be set >>>>>>>>>>>>>> with the fluent API >>>>>>>>>>> (and >>>>>>>>>>>>>> soon through the conference file). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ciao, R Il giorno 29/set/2012 16:45, >>>>>>>>>>>>>> "Olivier Lamy" <[email protected]> ha >>>>>>>>>>>>> scritto: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2012/9/29 Raffaele P. Guidi >>>>>>>>>>>>>>> <[email protected]>: >>>>>>>>>>>>>>>>>> At least for the moment he can >>>>>>>>>>>>>>>>>> provide a patch to be integrated >>>>>>>>>>> in DM >>>>>>>>>>>>>>> :-) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sure, but as lightning is not in any >>>>>>>>>>>>>>>> public mvn repo should its >>>>>>>>>>> code be >>>>>>>>>>>>>>>> re-published in our svn? Or what? >>>>>>>>>>>>>>> @Apache we don't care about binaries, >>>>>>>>>>>>>>> only sources are important ! (a bit >>>>>>>>>>>>>>> theorical for sure but that's it :-) ). >>>>>>>>>>>>>>> So if Noctarius was the only guy who >>>>>>>>>>>>>>> participate in lightning. He can just >>>>>>>>>>>>>>> provide a patch we could integrate as a >>>>>>>>>>>>>>> new dm module (note: the patch must not >>>>>>>>>>>>>>> contains any more copyright and all >>>>>>>>>>>>>>> sources must have ASF licenses). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> "Copyright 2012 the original author or >>>>>>>>>>>>>>> authors." must be removed. And BTW >>>>>>>>>>>>>>> package must be changed :-) (com.github >>>>>>>>>>>>>>> is not acceptable >>>>>>>>>>> @asf >>>>>>>>>>>>>>> :-) )(@Noctarius are you working for >>>>>>>>>>>>>>> github ? :-) ) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> And having him as a committer will be >>>>>>>>>>>>>>> only a matter of voting (we >>>>>>>>>>> have >>>>>>>>>>>>>>> a great chair who take cares of >>>>>>>>>>>>>>> administrative stuff :P ) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If some others have participated in the >>>>>>>>>>>>>>> project, we must pass tru an ip >>>>>>>>>>>>>>> clearance mechanism >>>>>>>>>>>>>>> (http://incubator.apache.org/ip-clearance/index.html) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>> >> and all contributors to lightning must provide a cla. >>>>>>>>>>>>>>> (It it's the case I can help) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> perso I'd like we avoid hard >>>>>>>>>>>>>>>>>> dependency on Unsafe as maybe >>>>>>>>>>>>>>>>>> some >>>>>>>>>>> use >>>>>>>>>>>>>>>> other jdks :-) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Well, I believe Unsafe is supported >>>>>>>>>>>>>>>> by Sun JDK, OpenJDK, IBM JDK and >>>>>>>>>>>>>>>> JRockit - and I believe that it is >>>>>>>>>>>>>>>> more than enough. Also keep in >>>>>>>>>>> mind >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>> we already have an alternative Unsafe >>>>>>>>>>>>>>>> based memory storage - and >>>>>>>>>>>>> although >>>>>>>>>>>>>>>> it's not thoroughly tested for >>>>>>>>>>>>>>>> performance it dramaticaly >>>>>>>>>>>>>>>> simplifies >>>>>>>>>>>>>>> code, >>>>>>>>>>>>>>>> I have great expectations about it. >>>>>>>>>>>>>>> Me too :-). Yup definitely more simple >>>>>>>>>>>>>>> and faster ! But we must provide a >>>>>>>>>>>>>>> switch off configuration mechanism if >>>>>>>>>>>>>>> some >>>>>>>>>>> users >>>>>>>>>>>>>>> don't want to use that (because Unsafe >>>>>>>>>>>>>>> is just "Unsafe" :-) ) And sorry I >>>>>>>>>>>>>>> didn't have a look yet at your changes >>>>>>>>>>>>>>> with using Unsafe. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Cheers, R >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Sat, Sep 29, 2012 at 4:03 PM, >>>>>>>>>>>>>>>> Olivier Lamy <[email protected]> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2012/9/29 Raffaele P. Guidi >>>>>>>>>>>>>>>>> <[email protected]>: >>>>>>>>>>>>>>>>>> What do you think about: 1) >>>>>>>>>>>>>>>>>> implementing a lightning >>>>>>>>>>>>>>>>>> serialization module 2) creating >>>>>>>>>>>>>>>>>> a serializer that directly works >>>>>>>>>>>>>>>>>> on a directmemory >>>>>>>>>>>>>>> provider >>>>>>>>>>>>>>>>>> ByteBuffer or (maybe better) >>>>>>>>>>>>>>>>>> Unsafe based Pointer? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Sounds good (perso I'd like we >>>>>>>>>>>>>>>>> avoid hard dependency on Unsafe as >>>>>>>>>>>>>>>>> maybe some use other jdks :-) ) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Now I see lightning is apache >>>>>>>>>>>>>>>>>> licensed and this is fine but I >>>>>>>>>>> don't >>>>>>>>>>>>>>> think >>>>>>>>>>>>>>>>>> it is published in any public >>>>>>>>>>>>>>>>>> maven repo, am I right? We could >>>>>>>>>>> find a >>>>>>>>>>>>>>> way >>>>>>>>>>>>>>>>>> to deal with this; options vary >>>>>>>>>>>>>>>>>> from publishing lightning to the >>>>>>>>>>> free >>>>>>>>>>>>>>>>>> sonatype repo, joining the ASF >>>>>>>>>>>>>>>>>> (which is great anyhow!) and >>>>>>>>>>>>>>> republishing >>>>>>>>>>>>>>>>>> lightning code in DirectMemory >>>>>>>>>>>>>>>>>> becoming a commiter (which has >>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>> undergo >>>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>>> PMC vote). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> At least for the moment he can >>>>>>>>>>>>>>>>> provide a patch to be integrated >>>>>>>>>>>>>>>>> in >>>>>>>>>>> DM >>>>>>>>>>>>>>> :-) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I'd like to hear your and the >>>>>>>>>>>>>>>>>> team feelings on this. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, Raffaele >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Sat, Sep 29, 2012 at 3:27 PM, >>>>>>>>>>>>>>>>>> Noctarius <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hey Raffaele, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> that's quite similar to what I >>>>>>>>>>>>>>>>>>> did at work. We're developing >>>>>>>>>>> Flash >>>>>>>>>>>>>>>>>>> online games and using a >>>>>>>>>>>>>>>>>>> customized AMF serialization. >>>>>>>>>>>>>>>>>>> To support async writing of the >>>>>>>>>>>>>>>>>>> clients event results I added >>>>>>>>>>>>>>>>>>> serialization >>>>>>>>>>> of >>>>>>>>>>>>>>>>>>> the components / entities to >>>>>>>>>>>>>>>>>>> the players zone calculation >>>>>>>>>>>>>>>>>>> and >>>>>>>>>>> stored >>>>>>>>>>>>>>>>>>> the pre-serialized bytestream >>>>>>>>>>>>>>>>>>> directly to the off-heap (using >>>>>>>>>>>>>>>>>>> direct-ring-cache >>>>>>>>>>>>>>>>>>> implementation). When the >>>>>>>>>>>>>>>>>>> client requests the results >>>>>>>>>>>>>>>>>>> (using long-polling) I just >>>>>>>>>>>>>>>>>>> write the pre-serialized >>>>>>>>>>> data to >>>>>>>>>>>>>>>>>>> the right position to >>>>>>>>>>>>>>>>>>> deserialize it by standard ways >>>>>>>>>>>>>>>>>>> on Flash >>>>>>>>>>> side. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> So yeah an seriliaztion to >>>>>>>>>>>>>>>>>>> off-heap algorithm would be >>>>>>>>>>>>>>>>>>> fine. You >>>>>>>>>>> can >>>>>>>>>>>>>>>>>>> avoid using byte arrays and >>>>>>>>>>>>>>>>>>> minimalize GC. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Cheers Chris >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Am 29.09.2012 15:02, schrieb >>>>>>>>>>>>>>>>>>> Raffaele P. Guidi: >>>>>>>>>>>>>>>>>>>> Nice to hear back from you! >>>>>>>>>>>>>>>>>>>> Yes, I was thinking about >>>>>>>>>>>>>>>>>>>> creating a >>>>>>>>>>>>>>> new >>>>>>>>>>>>>>>>>>> memory >>>>>>>>>>>>>>>>>>>> storage implementation using >>>>>>>>>>>>>>>>>>>> Unsafe (and I did it, >>>>>>>>>>>>>>>>>>>> recently) and >>>>>>>>>>>>>>>>> also, as >>>>>>>>>>>>>>>>>>>> DirectMemory relies heavily >>>>>>>>>>>>>>>>>>>> on serialization (and >>>>>>>>>>>>>>>>>>>> supports many >>>>>>>>>>> of >>>>>>>>>>>>>>>>> them, >>>>>>>>>>>>>>>>>>>> protostuff, protobuf, msgpack >>>>>>>>>>>>>>>>>>>> and of course standard >>>>>>>>>>>>>>> serialization), >>>>>>>>>>>>>>>>>>> about >>>>>>>>>>>>>>>>>>>> creating a simple embedded >>>>>>>>>>>>>>>>>>>> serializer leveraging the >>>>>>>>>>>>>>>>>>>> same >>>>>>>>>>>>>>> techniques >>>>>>>>>>>>>>>>> you >>>>>>>>>>>>>>>>>>>> used (Unsafe and bytecode >>>>>>>>>>>>>>>>>>>> generation). The idea with >>>>>>>>>>>>>>>>>>>> embedding is avoiding to >>>>>>>>>>>>>>>>>>>> serialize in a byte array >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>> then >>>>>>>>>>>>>>>>>>>> moving the byte array to >>>>>>>>>>>>>>>>>>>> off-heap memory (via Unsafe >>>>>>>>>>>>>>>>>>>> or >>>>>>>>>>>>>>> ByteBuffers), >>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>> serializing directly into a >>>>>>>>>>>>>>>>>>>> "managed" off-heap buffer, >>>>>>>>>>>>>>>>>>>> thus >>>>>>>>>>> further >>>>>>>>>>>>>>>>>>>> optimizing heap utilization >>>>>>>>>>>>>>>>>>>> (less GC). >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> What do you think about it? >>>>>>>>>>>>>>>>>>>> Does it make any sense to >>>>>>>>>>>>>>>>>>>> you? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Ciao, R >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Sat, Sep 29, 2012 at 2:40 >>>>>>>>>>>>>>>>>>>> PM, Noctarius >>>>>>>>>>>>>>>>>>>> <[email protected]> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Hey guys, >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Raffaele found out about a >>>>>>>>>>>>>>>>>>>>> project of mine (Lightning) >>>>>>>>>>>>>>>>>>>>> a few >>>>>>>>>>> weeks >>>>>>>>>>>>>>>>>>>>> ago. Lightning is a heavy >>>>>>>>>>>>>>>>>>>>> Unsafe and Bytecode >>>>>>>>>>>>>>>>>>>>> generation using >>>>>>>>>>>>>>>>>>>>> Serializer implementation. >>>>>>>>>>>>>>>>>>>>> He told me that he was >>>>>>>>>>>>>>>>>>>>> interested in adding >>>>>>>>>>>>>>>>>>>>> something similar to >>>>>>>>>>>>>>>>>>>>> DirectMemory and I would be >>>>>>>>>>>>>>>>>>>>> glad to >>>>>>>>>>>>>>> help >>>>>>>>>>>>>>>>>>>>> out in this. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Another project I started a >>>>>>>>>>>>>>>>>>>>> few days ago, since it was >>>>>>>>>>>>>>>>>>>>> needed >>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>> work is DirectRingCache. >>>>>>>>>>>>>>>>>>>>> The name not really meets >>>>>>>>>>>>>>>>>>>>> to actual implementation >>>>>>>>>>>>>>>>>>>>> since it's not yet a ring >>>>>>>>>>>>>>>>>>>>> buffer using cache. I >>>>>>>>>>>>>>> used >>>>>>>>>>>>>>>>>>>>> this for a >>>>>>>>>>>>>>>>>>>>> pre-serialization simple >>>>>>>>>>>>>>>>>>>>> bytestream cache with >>>>>>>>>>>>>>>>>>>>> self-growing buffers. It >>>>>>>>>>>>>>>>>>>>> could be nice to have >>>>>>>>>>>>>>>>>>>>> DirectMemory >>>>>>>>>>> having >>>>>>>>>>>>>>>>>>>>> raw "buffers" to write to >>>>>>>>>>>>>>>>>>>>> or to read from. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Here are the links from >>>>>>>>>>>>>>>>>>>>> the projects: >>>>>>>>>>>>>>>>>>>>> https://github.com/noctarius/Lightning >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>> >>>>>>>>>>>>>>>>>>>>> >> https://github.com/noctarius/direct-ring-cache >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>> It would be nice to help out since I really like >>>>>>>>> the idea of >>>>>>>>>>>>>>>>>>>>> DirectMemory and since >>>>>>>>>>>>>>>>>>>>> direct-ring-cache is some >>>>>>>>>>>>>>>>>>>>> kind of >>>>>>>>>>>>>>> reinventing >>>>>>>>>>>>>>>>>>>>> the wheel. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Cheers Noctarius (Chris) >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- Olivier Lamy Talend: >>>>>>>>>>>>>>>>> http://coders.talend.com >>>>>>>>>>>>>>>>> http://twitter.com/olamy | >>>>>>>>>>>>>>>>> http://linkedin.com/in/olamy >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- Olivier Lamy Talend: >>>>>>>>>>>>>>> http://coders.talend.com >>>>>>>>>>>>>>> http://twitter.com/olamy | >>>>>>>>>>>>>>> http://linkedin.com/in/olamy >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- Olivier Lamy Talend: >>>>>>>>>>> http://coders.talend.com >>>>>>>>>>> http://twitter.com/olamy | >>>>>>>>>>> http://linkedin.com/in/olamy >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- Olivier Lamy Talend: http://coders.talend.com >>>>>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>>>>> >>>>> >>>> >>> >> >> >
