All this euro-babble is giving me a headache -- especially since it's argumentative and irrelevent. (Unless one of you is seriously trying to suggest that IntelliJ should, and I quote, "implement JPeg or Fractal decompression on the memory stack" for the purpose of "deferring garbage collection until at least Tuesday.")
Kirk P.S. I don't mean to offend anyone. (Particularly the European benefactors of our splendid IDE) Wayne Elliott wrote: ><cough> > >From: "Dimiter" <[EMAIL PROTECTED]> > > >>Ahem, ahem... :) >> >>This is the most funny idea i've heard from a long time ago, it reminds >>me that when I was at age 12 I tought tat I cah compress sompressed file >>and then compress it again and again until I fit all my games on a >>single flopy disk :) >> > >Ah those were the days! You belittle yourself to right off these >childhood imaginings! Perhaps if a floppy disk had fallen on your head >while you were taking a bath, you would have had the appropriate >epiphany. Of course you are constrained in your example by singularity >of media (only floppy disks), but a plethora of options abound in our >case. See below... > >>The compression is achieved because low information content (or highly >>correlated signal if you prefer) the loseless JPEG compresses >>photographic images (which are highly corelated data) at 10% in the best >>case. Apart from solving the problem how would you split the code in 8x8 >>pixels (as prescribed in the JPEG standard) the transformed signal will >>have approximately the same size. >> > >I use JPeg and fractal compression merely as stepping stones to provoke >a more lateral approach. Consider the elements that we are storing in >memory (at the simplest level we have code and data segments) We simply >identify the data elements as having either lossy or lossless storage >requirements, and handle them appropriately. > >In either case depending on the frequency of access requirements, data >segment elements could sometimes be stored to disk rather than memory. >(Why waste memory on what are predominately static entities anyway?) > >As far as compressing code using lossy methods goes, consider using >CRC back checking to derive the original code from the lossy >decompressed version. In other words use lossy compresion on the code >and include well-engineered CRCs (or similar code cracking devices) to >act as hints for resolving the losses encountered during decompression. >i.e. the combination of lossy code with CRC hints are applied to an >algorithm that iteratively adjusts the code until the original CRC is >attained, and voila!, lossless code. > > >>BTW both the fractal and JPEG compressions are used in their lossy >>variants which makes them inappropriate for code. The memory compresion >>is done mostly with loseles statistical algorithms like the good old >>Huffman. It gives you maximum ratio of 5. if you have 512MB dedicated >>for IDEA (in fact if you had it you wouldn't have the trouble) it means >>1.5G "waiting buffer". >> > >As stated before > > alg(lossy(code) + hints + crc) = lossless(code) > >This approach, I expect, goes beyond the scope of this list, but does >serve to illustrate how we seem to spend a lot of time trying to squeeze >the contents of a pear shaped swimming pool into a leaky red bucket, >simply because we don't have a tropical beach at our disposal. > >>Assuming that on my 256MB heap the garbage >>collections occur at least every hour, it would mean that the 1.5GB >>would sufice for approx 6 hours... so you have to go to the beach really >>often :) >> > >This is not a bad thing, and waterproof laptops that can be mounted >on bodyboards will no doubt soon be more popular than portable mp4 >palm players and their ilk. > >They screwed up the material for my mantle. Its looks more like sackcloth >than anything I've seen at the royal drapiers. And for some reason they >have shaven my head. Oh these Spanish and there inauguration rituals! > >WPE >Madrid Februias 33.3 LP MONO > >PS. What with all our noses being on the moon, is it any wonder nobody >wants to wake up and smell the coffee. > >>=QUOTED============================================= >> >>Ahem... >> >>If you look at the source of Runtime.gc() (line 488) you'll see that it >>can be overridden. So, all that needs doing is to implement JPeg or >>Fractal decompression on the memory stack. In javart.dll (or its >>Linux equivalent - I think its called javalnx.so) the octal dump is >> >> : >>017 AF02 00001100100100010001 >>018 AD02 0000100100701000!111 >> : >> >>which is the generic machine code for BITSET RAMPUSH >> >>So as long as memory is stored compressed (because it is just >>zeroes and one's remember) I see no problem deferring garbage >>collection until at least Tuesday. >> >>=END=QUOTED============================================= >> > > >_______________________________________________ >Eap-features mailing list >[EMAIL PROTECTED] >http://www.intellij.com/mailman/listinfo/eap-features > > _______________________________________________ Eap-features mailing list [EMAIL PROTECTED] http://www.intellij.com/mailman/listinfo/eap-features
