@IsmaelMiguel Are you golfing it, or what?

@IsmaelMiguel That's cool! The compressor must compress more than its own length?

They might not want it golfed, you know.

@Hosch250 No. I'm writting a library to send Javascript code inside a PNG image. And I have 'encoders' used to crush the size of the code. One of them is a static dictionary that has common stuff like 'function(){}', which then replaces it with \xFF\x<position on the dictionary>

Which means that function(){} would be sent as 2 color values in an image

Interesting - essentially, a standard lossless compression technique.

Except, I don't know if they usually use images.

@Caridorc It has to reduce as much as possible.

@Hosch250 Almost like that, yes.

And I use PNG images for caching purposes and for easiness

Besides, PNG also have their compression and aren't lossless

@IsmaelMiguel but if it compresses less than its own length then you lose the benefit right?

@IsmaelMiguel PNG is lossless. JPG isn't.

@Caridorc Exactly. The benefict is a small image vs. a huge text file.

@Hosch250 I know, and that is what I meant. Being lossless, I can write and read back the same exact data without any problem

I figured, but you said "aren't lossless".

I mean't "are lossless"

That is jQuery, using an older version

Abstract art?

Nope

You could frame it and sell it on Ebay.

That one is a newer version

@IsmaelMiguel that image is tiny! How many bytes of code does it contain?

It contains around 84347 bytes of Javascript code (jQuery)

"Around" because it does basic minimification before putting it into an image

Like removing spaces, newlines, comment removal

pastebin.com/XAqEYxNx

That is the dictionary data used to "compress" the code

@IsmaelMiguel using consistent formatting improves readibility and makes compression easier

It is meant to compress anything.

'while(true){', 'while(true) {', 'while (true) {', 'while (true)', 'while (1)', 'while(true)', 'while(1)', could all be merged

Users write whatever the heck goes by their heads

Besides, I have a limit of 254 entries

And only have around 90

@IsmaelMiguel yes, I mean running the code in a formatter before compressing it, like you probably would do anyway for readibility

If you had the machine power, you could look for repeating patterns in the text and generate 254 entries (if there were 254+ patterns of at least 2 characters) based on the top patterns.

@Hosch250 I have. That would be the 4th encoder. These are made just for code.

You could probably write a peer-reviewed article on the process.

@Caridorc Many persons don't do that.

@Hosch250 I highly doubt it

I've seen some that are quite similar.

Where?

@IsmaelMiguel Well, I like things with double benefits

If you had someone to get you into a journal and were a good writer, you probably could.

Compression is cool

But this is just something for the fun

Different journals published by groups such as IEEE and Ebsco MEGAshare.

Not something 200% serious

Darn, I have to remove a full page of my paper.

@Caridorc I like too, but I don't want my code to ocupy 2x more just because I forgot a space after a while

@Hosch250 Need help?

No. This is a school paper.

I'll probably just cut the section on the application layer.

grabs large scissors We can fix this reaaaal quick!

There goes PGP.

Oh well, Good night everyone

Night.

night

Night @Caridorc

night

Have a good night

@Phrancis Are you going to post a follow-up?

Hey @NᴏᴠɪᴄᴇIɴDɪsɢᴜɪsᴇ nice to meet you

Hello

@Hosch250 Maybe, depends if time allows

I pop by every now and then, but not often. I hang around The Renderfarm more often

You should get VS if you are planning on doing more.

I have VS on my work PC, which I don't own. So I might try moving it there eventually

I took PGP and TLS out. This should be good.

@IsmaelMiguel By the way, Ismael, have you tried just zipping the data into your image, and seeing what size you get for jQuery then? (In other words, even though it is interesting to reinvent the wheel from time to time, is it worth it size wize? Or is it better to use a well known zip engine?)

@holroy The libraries to compress the data using deflate, for Javascript, take around 30-90kb

My library is 15725 bytes now (I'm always changing something in it)

You have to remember that you need deflate to decompress the data too

Which means, you need that library

It isn't worth it

@IsmaelMiguel That big? That's too big. I made a zip implementation in C which was a lot smaller, and which could be implemented in javascript (I think) for a lot less than 30-90kb. It would be interesting though to see how much standard zipping would compress the jQuery. You don't have any numbers on it?

@IsmaelMiguel If the deflate lib takes 30-90 kb, you are true that it isn't worth it.

That is, it isn't worth it to use those libraries...

I don't have any numbers, but using gzip compression on server-side may reduce the size by around the same size

Or less

Come again? For the 84 kb jQuery file, the corresponding zip file was how big?

84kb is the minimified library

I've applied other ultra basic minimifications without much benefict

And then I used my static dictionary to compress it

Using gzip, it is 31.4kb

I don't know about gzip

Ah... There is the number I was looking for. So your current code reduced the size by 20 kb, but your library is 4KB. Net gain: 84kb to 68KB.

My library is 15725 bytes

Using a zip library, your net gain would be 84KB kb to 31.4KB + zip library. So implementing a zipper in less than 30 KB would be more space efficient...

The net gain, a while ago, was 4484 bytes

what about using a simple huffman-encoding?

I don't know how that works

You basically order each char by number of occurrences, then build a tree from that and encode depending on the path from root to leaf

That would take very massive power from Javascript

@Vogel612 Hey, you're beating me to my punch line! :-)

@IsmaelMiguel meh. not really..

the reverse is basically a lookup from binary code to character

I could try asm.js

It takes little power to deflate, but it requires a little to inflate. But not that much!

it takes less to inflate than to deflate probably.

you could store it with an encoding-table

Sorry switched them around...

and you can even cache the deflated version, so that cost is de-facto zeroed

Yes, but images are better cached than Javascript files

I've made a test

I ran jsfiddle in the middle of nowhere, using an EDGE connection

The zipper I was talking about in a lot less code lines is a variant over the huffman encoding. And you can still store it as an image

wait wat...

It took 17 seconds to download 68950 bytes

Then, I added an alert before the image was loaded

Then I disconnected

And the image was loaded from cache