Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #22375 > unrolled thread

Compressing js file?

Back to article view | Back to comp.lang.javascript

Contents

  Compressing js file? emf <emfril@gmail.com> - 2013-12-23 14:31 -0500
    Re: Compressing js file? Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2013-12-23 22:08 -0200
    Re: Compressing js file? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2013-12-23 16:40 -0800
      Re: Compressing js file? emf <emfril@gmail.com> - 2013-12-24 13:23 -0500
      Re: Compressing js file? emf <emfril@gmail.com> - 2013-12-26 21:56 -0500
        Re: Compressing js file? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2013-12-27 09:52 +0100
          Re: Compressing js file? emf <emfril@gmail.com> - 2013-12-27 08:18 -0500
            Re: Compressing js file? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2013-12-27 16:59 +0100
              Re: Compressing js file? emf <emfril@gmail.com> - 2013-12-27 15:32 -0500
                Re: Compressing js file? emf <emfril@gmail.com> - 2013-12-28 15:12 -0500
                  Re: Compressing js file? emf <emfril@gmail.com> - 2014-01-01 02:17 -0500
          Re: Compressing js file? Dr J R Stockton <reply1300@merlyn.demon.co.uk.invalid> - 2013-12-28 20:20 +0000
        XHR with timing issues (was: Compressing js file?) Christoph Michael Becker <cmbecker69@arcor.de> - 2013-12-27 22:33 +0100
          Re: XHR with timing issues (was: Compressing js file?) Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-12-27 23:26 +0100
            Re: XHR with timing issues Christoph Michael Becker <cmbecker69@arcor.de> - 2013-12-28 12:08 +0100
              Re: XHR with timing issues emf <emfril@gmail.com> - 2013-12-28 09:04 -0500
    Re: Compressing js file? wolfgang zeidler <invalid@invalid.invalid> - 2013-12-27 22:33 +0100
      Re: Compressing js file? emf <emfril@gmail.com> - 2013-12-28 00:16 -0500
        Re: Compressing js file? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2013-12-28 11:13 +0100
          Re: Compressing js file? emf <emfril@gmail.com> - 2013-12-28 11:26 -0500
            Re: Compressing js file? emf <emfril@gmail.com> - 2013-12-28 13:53 -0500
              Re: Compressing js file? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2013-12-28 21:00 +0100
                Re: Compressing js file? emf <emfril@gmail.com> - 2013-12-29 21:47 -0500
                  Re: Compressing js file? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2013-12-31 14:05 -0800
                    Re: Compressing js file? emf <emfril@gmail.com> - 2014-01-01 02:50 -0500
                      Re: Compressing js file? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-01-01 01:16 -0800
                        Re: Compressing js file? emf <emfril@gmail.com> - 2014-01-01 08:13 -0500
                          Re: Compressing js file? Tim Streater <timstreater@greenbee.net> - 2014-01-01 14:17 +0000
                          Re: Compressing js file? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-01-01 15:31 -0800
                          Re: Compressing js file? emf <emfril@gmail.com> - 2014-01-01 18:38 -0500
                            Re: Compressing js file? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-01-01 15:45 -0800
                              Re: Compressing js file? emf <emfril@gmail.com> - 2014-01-02 11:43 -0500
                                Re: Compressing js file? "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2014-01-02 09:34 -0800
                                  OT: Compressing js file? Christoph Michael Becker <cmbecker69@arcor.de> - 2014-01-02 19:52 +0100
                                  Re: Compressing js file? emf <emfril@gmail.com> - 2014-01-03 07:19 -0500
                                  Re: Compressing js file? emf <emfril@gmail.com> - 2014-01-03 07:31 -0500
                            Re: Compressing js file? Tim Streater <timstreater@greenbee.net> - 2014-01-02 09:14 +0000
                      Re: Compressing js file? Denis McMahon <denismfmcmahon@gmail.com> - 2014-01-01 16:25 +0000
                        Re: Compressing js file? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-01-01 21:36 +0100
            Re: Compressing js file? wolfgang zeidler <invalid@invalid.invalid> - 2013-12-29 20:06 +0100
              Re: Compressing js file? wolfgang zeidler <invalid@invalid.invalid> - 2013-12-29 20:27 +0100
          Re: Compressing js file? Dr J R Stockton <reply1300@merlyn.demon.co.uk.invalid> - 2013-12-29 18:02 +0000
            Re: Compressing js file? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2013-12-30 18:17 +0100
              Re: Compressing js file? John Harris <niam@jghnorth.org.uk.invalid> - 2013-12-31 10:52 +0000
              Re: Compressing js file? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2013-12-31 13:38 +0000
                Re: Compressing js file? John Harris <niam@jghnorth.org.uk.invalid> - 2013-12-31 15:02 +0000
                  Re: Compressing js file? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-01-01 16:42 +0000
                  Re: Compressing js file? Dr J R Stockton <reply1400@merlyn.demon.co.uk.invalid> - 2014-01-01 21:32 +0000
              Re: Compressing js file? Dr J R Stockton <reply1300@merlyn.demon.co.uk.invalid> - 2013-12-31 21:44 +0000

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#22454

On 2013-12-28 11:26 emf wrote:
> On 2013-12-28 05:13 Evertjan. wrote:
>> emf <emfril@gmail.com> wrote on 28 dec 2013 in comp.lang.javascript:
>>
>>> Another idea is to omit the date altogether. And if I use csv instead,
>>>
>>> [19000101,"27i43","10i08"],.  : 28 characters
>>> becomes
>>> 27i43,10i08.   : 12 characters
>>>
>>> which is about 57% reduction. Then I would subtract 1900-01-01 from the
>>> one entered to get the index of the array and avoid going through a
>>> loop.
>>>
>>> I'll have to consider these and your other suggestions after I have
>>> given up on compressing the file. If I could compress it, I won't
>>> consider further reductions necessary.
>>
>> While I do not see much use in compression,
>> integer math is fun,
>> so if you want it, try to compress/decompress to/from base 36,
>> using the functions Javascript has in store,
>> toString() and parseInt():
>>
>> <script type="text/javascript">
>>
>> dateCompression(19130101);
>> dateCompression(20131228);
>>
>> function dateCompression(d) {
>>         document.write(d + ' [original number]<br>');
>>     var substrac = 19500000;
>>     d = d - substrac;
>>     var dCompressed = d.toString(36).toUpperCase();
>>         document.write(dCompressed + ' [string base 36]<br>');
>>     var dNew = parseInt(dCompressed,36) + substrac;
>>         document.write(dNew + ' [reconstructed number]<br><br>');
>> };
>>
>> </script>
>>
>> The number dnew is in binary
>> expressed as a decimal string by document.write(),
>> while the base 36 is a string by itself.
>>
>> The inputparameter d can be a number or string, try:
>>
>> dateCompression('19130101');
>
> As I said elsewhere, eventually I may consider eliminating the date
> altogether. I am wondering, however, if I could compress the planetary
> positions, which can be expressed as integer minutes. (For example,
> 17c22 equals (((c-a)*30) + 17) * 60 + 22, where c-a = 2.) How much could
> I save compressing these?
>
> emf

Sorry for mu rush reply. I replied before thinking about it. Of course, 
with a 36 base system the planetary positions can be expressed with a 3 
digit string. So

[19000101,"27i43","10i08"],.

can become

["xyz","syz"],

which is 50$ smaller, or

xyz,xyz.

which is only 8 characters compared to 27, that's less than 33% of the 
cs file.

I hadn't thought that this is what compression does. I'll come back to 
this when I solve the double clicking problem.

Thanks,

emf

-- 
Google's top Spherical Triangle Calculator search result!
https://files.nyu.edu/emf202/public/js/spherical.html

[toc] | [prev] | [next] | [standalone]

#22455

emf <emfril@gmail.com> wrote on 28 dec 2013 in comp.lang.javascript:

> Sorry for mu rush reply. I replied before thinking about it. Of course, 
> with a 36 base system the planetary positions can be expressed with a 3 
> digit string. So
> 
> [19000101,"27i43","10i08"],.
> 
> can become
> 
> ["xyz","syz"],
> 
> which is 50$ smaller, or
> 
> xyz,xyz.
> 
> which is only 8 characters compared to 27, that's less than 33% of the 
> cs file.
> 
> I hadn't thought that this is what compression does. I'll come back to 
> this when I solve the double clicking problem.

369 * 60 = 21600 
2 ^ 15 = 32768
So you can express your postion easily with 15 bits.
2 8-bit-bytes is 16 bits.

So if you use a binary type file, without "defined" characters,
you would only need 2 bytes/characters per position.

You can construct a line of those 2-byte-positions 
where the first bit of the 16 is always a 0,
with a occasional [say one in 16?] synchronizing 2-byte 
being at the same time a numbered pointer, 
with the top bit a 1.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#22488

On 2013-12-28 15:00 Evertjan. wrote:
> emf <emfril@gmail.com> wrote on 28 dec 2013 in comp.lang.javascript:
>
>> Sorry for mu rush reply. I replied before thinking about it. Of course,
>> with a 36 base system the planetary positions can be expressed with a 3
>> digit string. So
>>
>> [19000101,"27i43","10i08"],.
>>
>> can become
>>
>> ["xyz","syz"],
>>
>> which is 50$ smaller, or
>>
>> xyz,xyz.
>>
>> which is only 8 characters compared to 27, that's less than 33% of the
>> cs file.
>>
>> I hadn't thought that this is what compression does. I'll come back to
>> this when I solve the double clicking problem.
>
> 369 * 60 = 21600
> 2 ^ 15 = 32768
> So you can express your postion easily with 15 bits.
> 2 8-bit-bytes is 16 bits.
>
> So if you use a binary type file, without "defined" characters,
> you would only need 2 bytes/characters per position.
>
> You can construct a line of those 2-byte-positions
> where the first bit of the 16 is always a 0,
> with a occasional [say one in 16?] synchronizing 2-byte
> being at the same time a numbered pointer,
> with the top bit a 1.

All these messages on compression I've been reading are interesting and 
terra incognita yet for me, but let me update you to the point I have 
reached so far.

I have updated

https://files.nyu.edu/emf202/public/nt/nataltransits.html

so that it now uses

https://files.nyu.edu/emf202/public/nt/ephemeris.csv

which contains on each line only the 2 planetary positions:

27i43	10i08
...

Instead of the loop to find the correct line, I calculate directly the 
index of the array, which is actually a cleaner way to go after it.

(Note for other poster: the letters represent the signs of the zodiac in 
ASCII characters. For example 27i43 means 27° ♐ 43', and hence they can 
be changed to minutes from the beginning of the zodiac. I have no idea 
how they could be calculated, since sometimes the planets appear to 
retrograde, that is they seem to move backwards on the celestial sphere.)

The programs runs OK (I am still testing locally at this stage) except 
for the original double-click, which I suppose nobody is exactly sure 
why it is necessary. The size of the csv file is 696 KB (remember that 
my original js was 1606 KB) and hence less than the total jar of the 
Java program. Of course the Java program could calculate the transits of 
5 planets, but of these only 2 are actually important for my current 
purposes, and besides with the the JavaScript program I am able to use 
Unicode symbols, something that was problematic in Java and I had 
avoided it.

Now, using my 7zip I've made a gz file of the csv and it is only 153 KB:

https://files.nyu.edu/emf202/public/nt/ephemeris.csv.gz

153 KB would be great. But how do I access the csv inside the gz?

Thanks,

Eustace

-- 
Natal Transits Calculator
https://files.nyu.edu/emf202/public/nt/nataltransits.html

[toc] | [prev] | [next] | [standalone]

#22497

On Sunday, December 29, 2013 8:47:35 PM UTC-6, emf wrote:

> Now, using my 7zip I've made a gz file of the csv and it is only 153 KB:
> 
> https://files.nyu.edu/emf202/public/nt/ephemeris.csv.gz
> 
> 153 KB would be great. But how do I access the csv inside the gz?

Google ate my last message, so I'll try again and much terser:

Look at the following article:

<http://betterexplained.com/articles/how-to-optimize-your-site-with-gzip-compression/>

See an example:

<http://thenewobjective.com/temp/csv-gzip>

Notice that in my case I left the csv uncompressed on the server, but it was downloaded in compressed form. Your server set up may be different depending on its default setup and platform but in my case I simply added an .htaccess file to the folder with a single line:

AddOutputFilterByType DEFLATE text/csv

If it's IIS:

<http://stackoverflow.com/questions/1324481/setting-the-gzip-compression-in-asp-net>

[toc] | [prev] | [next] | [standalone]

#22501

On 2013-12-31 17:05 Michael Haufe (TNO) wrote:
> On Sunday, December 29, 2013 8:47:35 PM UTC-6, emf wrote:
>
>> Now, using my 7zip I've made a gz file of the csv and it is only 153
>> KB:
>>
>> https://files.nyu.edu/emf202/public/nt/ephemeris.csv.gz
>>
>> 153 KB would be great. But how do I access the csv inside the gz?
>
> Google ate my last message, so I'll try again and much terser:
>
> Look at the following article:
>
> <http://betterexplained.com/articles/how-to-optimize-your-site-with-gzip-compression/>
>
> See an example:
>
> <http://thenewobjective.com/temp/csv-gzip>
>
> Notice that in my case I left the csv uncompressed on the server, but
> it was downloaded in compressed form. Your server set up may be
> different depending on its default setup and platform but in my case I
> simply added an .htaccess file to the folder with a single line:
>
> AddOutputFilterByType DEFLATE text/csv

>
> If it's IIS:
>
> <http://stackoverflow.com/questions/1324481/setting-the-gzip-compression-in-asp-net>

Let me update you on what I've been working on:

I created an ephemeris.b36.csv file, with the planetary positions in 
base 36 minutes, 3 characters each - 4 with the c or HRt; it is 482 KB 
while the ephemeris.csv was 696 KB, where each position was 5 (/ 6). The 
difference is significant but for practical purposes not too impressive: 
both are a little large.

Then I gzipped it too: to my surprise its size was 153 KB, exactly the 
same as the gz of the ephemeris.csv. So if the files are delivered 
gzipped from the server, having the ephemeris data in base 36 does not 
make any difference.

In which folder did you put the .htaccess file? The temp? And what is 
the filename of the file?

Thanks,

Eustace

-- 
Natal Transits Calculator
https://files.nyu.edu/emf202/public/nt/nataltransits.html

[toc] | [prev] | [next] | [standalone]

#22502

On Wednesday, January 1, 2014 1:50:22 AM UTC-6, emf wrote:

> In which folder did you put the .htaccess file? The temp? And what is 
> the filename of the file?

Under csv-gzip

The name of the file is ephemeris.csv

[toc] | [prev] | [next] | [standalone]

#22503

On 2014-01-01 04:16 Michael Haufe (TNO) wrote:
> On Wednesday, January 1, 2014 1:50:22 AM UTC-6, emf wrote:
>
>> In which folder did you put the .htaccess file? The temp? And what is
>> the filename of the file?
>
> Under csv-gzip
>
> The name of the file is ephemeris.csv

Thanks, but I am sorry, I still do not understand.

You write:

 > in my case I simply added an .htaccess file to the folder with a
 > single line:
 >
 > AddOutputFilterByType DEFLATE text/csv

So in my case I should try to add a file with this line inside my nt 
directory, where the ephemeris.csv (or maybe the ephemeris.b36.csv if I 
decide to use it instead) resides.

My question is: what should be the name (filename.extension) of this 
single-line file?

BTW, according to the http://www.whatsmyip.org/http-compression-test/ 
the ephemeris.csv from 695.54 KB will be compressed to 224.52 KB (67.72% 
savings), while the ephemeris.b36.csv from 481.53 KB will become 220.86 
KB (54.13%).

Also, about what percent of the browsers are not able to inflate gz 
files sent by the server? If the percent is very small, I won't bother 
with base 36.

emf
-- 
Google's top Spherical Triangle Calculator search result!
https://files.nyu.edu/emf202/public/js/spherical.html

[toc] | [prev] | [next] | [standalone]

#22504

In article <la149u$7mu$1@speranza.aioe.org>, emf <emfril@gmail.com>
wrote:

> On 2014-01-01 04:16 Michael Haufe (TNO) wrote:
> > On Wednesday, January 1, 2014 1:50:22 AM UTC-6, emf wrote:
> >
> >> In which folder did you put the .htaccess file? The temp? And what is
> >> the filename of the file?
> >
> > Under csv-gzip
> >
> > The name of the file is ephemeris.csv
> 
> Thanks, but I am sorry, I still do not understand.
> 
> You write:
> 
>  > in my case I simply added an .htaccess file to the folder with a
>  > single line:
>  >
>  > AddOutputFilterByType DEFLATE text/csv
> 
> So in my case I should try to add a file with this line inside my nt 
> directory, where the ephemeris.csv (or maybe the ephemeris.b36.csv if I 
> decide to use it instead) resides.
> 
> My question is: what should be the name (filename.extension) of this 
> single-line file?

.htaccess

as was said.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#22510

On Wednesday, January 1, 2014 7:13:38 AM UTC-6, emf wrote:

> Also, about what percent of the browsers are not able to inflate gz 
> files sent by the server? If the percent is very small, I won't bother 
> with base 36.

The only one you might be concerned with is IE5.5 and IE6. They can do it but is buggy.

Here is a more comprehensive list (though dated):
<http://schroepl.net/projekte/mod_gzip/browser.htm>

[toc] | [prev] | [next] | [standalone]

#22511

On 2014-01-01 08:13 emf wrote:
> On 2014-01-01 04:16 Michael Haufe (TNO) wrote:
>> On Wednesday, January 1, 2014 1:50:22 AM UTC-6, emf wrote:
>>
>>> In which folder did you put the .htaccess file? The temp? And what is
>>> the filename of the file?
>>
>> Under csv-gzip
>>
>> The name of the file is ephemeris.csv
>
> Thanks, but I am sorry, I still do not understand.
>
> You write:
>
>  > in my case I simply added an .htaccess file to the folder with a
>  > single line:
>  >
>  > AddOutputFilterByType DEFLATE text/csv
>
> So in my case I should try to add a file with this line inside my nt
> directory, where the ephemeris.csv (or maybe the ephemeris.b36.csv if I
> decide to use it instead) resides.
>
> My question is: what should be the name (filename.extension) of this
> single-line file?
>
> BTW, according to the http://www.whatsmyip.org/http-compression-test/
> the ephemeris.csv from 695.54 KB will be compressed to 224.52 KB (67.72%
> savings), while the ephemeris.b36.csv from 481.53 KB will become 220.86
> KB (54.13%).http://www.whatsmyip.org/http-compression-test/?url=aHR0cHM6Ly9maWxlcy5ueXUuZWR1L2VtZjIwMi9wdWJsaWMvbnQvZXBoZW1lcmlzLmNzdg==
>
> Also, about what percent of the browsers are not able to inflate gz
> files sent by the server? If the percent is very small, I won't bother
> with base 36.
>
> emf

I found out how to make a file in Windows without a filename - I had 
tried and I had thought that it was not possible.

I added the file in the directory

https://files.nyu.edu/emf202/public/nt/

Unfortunately, my server does not seem to support it according to the 
compression test. So unless there is some other way, a 500 KB data file 
will have to do.

BTW, I've opted for ephemeris.b36.csv, but is there a commonly used 
extension for base 36 csv files?

Eustace

-- 
Natal Transits Calculator
https://files.nyu.edu/emf202/public/nt/nataltransits.html

[toc] | [prev] | [next] | [standalone]

#22513

On Wednesday, January 1, 2014 5:38:28 PM UTC-6, emf wrote:
> 
> I found out how to make a file in Windows without a filename - I had 
> tried and I had thought that it was not possible.
> 
> I added the file in the directory
> 
> https://files.nyu.edu/emf202/public/nt/
> 
> Unfortunately, my server does not seem to support it according to the 
> compression test. So unless there is some other way, a 500 KB data file 
> will have to do.

Your server is not sending the csv as text/csv, it is sending it to the browser as: "application/vnd.ms-excel"

So either update the server to send the right content type, or update the .htaccess file to use this new content type.

You can also perform the encoding based on file extension, but the better way is to do it based on content-type.

> BTW, I've opted for ephemeris.b36.csv, but is there a commonly used 
> extension for base 36 csv files?

I don't think there is one.

[toc] | [prev] | [next] | [standalone]

#22517

On 2014-01-01 18:45 Michael Haufe (TNO) wrote:
> On Wednesday, January 1, 2014 5:38:28 PM UTC-6, emf wrote:
>>
>> I found out how to make a file in Windows without a filename - I had
>> tried and I had thought that it was not possible.
>>
>> I added the file in the directory
>>
>> https://files.nyu.edu/emf202/public/nt/
>>
>> Unfortunately, my server does not seem to support it according to the
>> compression test. So unless there is some other way, a 500 KB data file
>> will have to do.
>
> Your server is not sending the csv as text/csv, it is sending it to the
> browser as: "application/vnd.ms-excel"
>
> So either update the server to send the right content type, or update
> the .htaccess file to use this new content type.

Thanks. I updated the .htaccess file:

   AddOutputFilterByType DEFLATE application/vnd.ms-excel

Unfortunately, the Http Compression Text is still negative:

   https://files.nyu.edu/emf202/public/nt/ephemeris.csv is not gzipped

Unless there is another solution, I think I'll have to contact the NYU 
IT department and see what they will say.

emf

-- 
It ain't THAT, babe! - A radical reinterpretation
https://files.nyu.edu/emf202/public/bd/itaintmebabe.html

[toc] | [prev] | [next] | [standalone]

#22518

On Thursday, January 2, 2014 10:43:48 AM UTC-6, emf wrote:
> 
> Thanks. I updated the .htaccess file:
> 
>    AddOutputFilterByType DEFLATE application/vnd.ms-excel
> 
> Unfortunately, the Http Compression Text is still negative:
> 
>    https://files.nyu.edu/emf202/public/nt/ephemeris.csv is not gzipped
> 
> Unless there is another solution, I think I'll have to contact the NYU 
> IT department and see what they will say.

According to Chrome's network inspector, now it's being served as application/octet-stream.

Something definitely screwy with your server. Perhaps try the other method listed in the earlier mentioned article and do it based on file-extension. Otherwise I'd agree with you to talk to IT and see what is going on with the settings

[toc] | [prev] | [next] | [standalone]

#22519 — OT: Compressing js file?

Michael Haufe (TNO) wrote:

> On Thursday, January 2, 2014 10:43:48 AM UTC-6, emf wrote:
>> 
>> Thanks. I updated the .htaccess file:
>> 
>> AddOutputFilterByType DEFLATE application/vnd.ms-excel
>> 
>> Unfortunately, the Http Compression Text is still negative:
>> 
>> https://files.nyu.edu/emf202/public/nt/ephemeris.csv is not
>> gzipped
>> 
>> Unless there is another solution, I think I'll have to contact the
>> NYU IT department and see what they will say.
> 
> According to Chrome's network inspector, now it's being served as
> application/octet-stream.

Indeed.  However, the server sends:

  Content-Type: application/vnd.ms-excel

What is missing, ISTM, is the appropriate Content-Encoding header.
Maybe mod_deflate is enabled on this server, or the server ignores
.htaccess files at all.

> Something definitely screwy with your server. Perhaps try the other
> method listed in the earlier mentioned article and do it based on
> file-extension. Otherwise I'd agree with you to talk to IT and see
> what is going on with the settings

ACK.  An alternative might be to ask in a more appropriate newsgroup,
e.g. comp.infosystems.www.servers.unix.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#22523

On 2014-01-02 12:34 Michael Haufe (TNO) wrote:
> On Thursday, January 2, 2014 10:43:48 AM UTC-6, emf wrote:
>>
>> Thanks. I updated the .htaccess file:
>>
>>     AddOutputFilterByType DEFLATE application/vnd.ms-excel
>>
>> Unfortunately, the Http Compression Text is still negative:
>>
>>     https://files.nyu.edu/emf202/public/nt/ephemeris.csv is not gzipped
>>
>> Unless there is another solution, I think I'll have to contact the NYU
>> IT department and see what they will say.
>
> According to Chrome's network inspector, now it's being served as
> application/octet-stream.

I tried

AddOutputFilterByType DEFLATE application/octet-stream

No effect.

> Something definitely screwy with your server. Perhaps try the other
> method listed in the earlier mentioned article and do it based on file
>-extension.

I also tried

<files *.csv>
SetOutputFilter DEFLATE
</files>

Again no effect.
> Otherwise I'd agree with you to talk to IT and see what is
> going on with the settings

I will, but somehow I expect a negative reaction from them. The 
files.nyu.edu is aimed primarily as a document storage and sharing 
facility, not as a web-hosting one. Once I asked them how I could use a 
submit in a form to receive the input in a form of a webpage. I can't. 
They advised me to use a Google something that is available.

emf

-- 
Natal Transits Calculator
https://files.nyu.edu/emf202/public/nt/nataltransits.html

[toc] | [prev] | [next] | [standalone]

#22524

On 2014-01-02 12:34 Michael Haufe (TNO) wrote:
> On Thursday, January 2, 2014 10:43:48 AM UTC-6, emf wrote:
>>
>> Thanks. I updated the .htaccess file:
>>
>>     AddOutputFilterByType DEFLATE application/vnd.ms-excel
>>
>> Unfortunately, the Http Compression Text is still negative:
>>
>>     https://files.nyu.edu/emf202/public/nt/ephemeris.csv is not gzipped
>>
>> Unless there is another solution, I think I'll have to contact the NYU
>> IT department and see what they will say.
>
> According to Chrome's network inspector, now it's being served as
> application/octet-stream.
>
> Something definitely screwy with your server. Perhaps try the other
> method listed in the earlier mentioned article and do it based on file
>-extension. Otherwise I'd agree with you to talk to IT and see what is
> going on with the settings

The article also mentions using PHP

============
If you can't change your .htaccess file, you can use PHP to return 
compressed content. Give your HTML file a .php extension and add this 
code to the top:

In PHP:

<?php if (substr_count($_SERVER['HTTP_ACCEPT_ENCODING'], 'gzip')) 
ob_start("ob_gzhandler"); else ob_start(); ?>
============

The issue is that I do not need the csv not the html file to be 
deflated. And I can't apply this to the csv, or can I?

emf

-- 
Google's top Spherical Triangle Calculator search result!
https://files.nyu.edu/emf202/public/js/spherical.html

[toc] | [prev] | [next] | [standalone]

#22516

In article <la28ti$5k6$1@speranza.aioe.org>, emf <emfril@gmail.com>
wrote:

> I found out how to make a file in Windows without a filename - I had 
> tried and I had thought that it was not possible.

.htaccess *is* the filename. I already told you that.

> BTW, I've opted for ephemeris.b36.csv, but is there a commonly used 
> extension for base 36 csv files?

What is this fixation with extensions that you have?

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#22505

On Wed, 01 Jan 2014 02:50:22 -0500, emf wrote:

> I created an ephemeris.b36.csv file, with the planetary positions in
> base 36 minutes, 3 characters each - 4 with the c or HRt; it is 482 KB
> while the ephemeris.csv was 696 KB, where each position was 5 (/ 6). The
> difference is significant but for practical purposes not too impressive:
> both are a little large.
> 
> Then I gzipped it too: to my surprise its size was 153 KB, exactly the
> same as the gz of the ephemeris.csv.

That's not a great surprise if you understand how file compression 
algorithms work. I only have a very loose understanding of such things, 
but basically they use various combinations of different compression 
techniques, one of which is to remove redundant bits.

For example, if you are compressing n digit numbers as base 10 ascii 
strings, you are generally using 8n bits of data to express a value in 
something of the order of 3.5n bits.

By converting the numeric data to base 36, you have in effect performed a 
form of tokenization which would otherwise be done by the compression 
algorithm.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#22508

Denis McMahon <denismfmcmahon@gmail.com> wrote on 01 jan 2014 in 
comp.lang.javascript:

> By converting the numeric data to base 36, you have in effect performed a 
> form of tokenization which would otherwise be done by the compression 
> algorithm.

I wouldn't call using increased base notation compression, 
however it has a nice effect of debuggability 
by keeping the individual numbers humanly readable.

===================

Do you need this compression ?????????????????

In general I don't think you need to download large databases for clientside 
use in a online webpage, as the amount of date actualy used would probably 
be relatively very small and can better be requested using Jason-like 
techniques.

Google maps does not send all available terrain images of our planet if you 
only want to see the fenced-off garden arrangements of your neighbour.


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#22477

emf wrote:
> On 2013-12-28 05:13 Evertjan. wrote:
>> emf <emfril@gmail.com> wrote on 28 dec 2013 in comp.lang.javascript:
>>
>>> Another idea is to omit the date altogether. And if I use csv instead,
>>>
>>> [19000101,"27i43","10i08"],.  : 28 characters
>>> becomes
>>> 27i43,10i08.   : 12 characters
>>>
>>> which is about 57% reduction. Then I would subtract 1900-01-01 from the
>>> one entered to get the index of the array and avoid going through a
>>> loop.
>>>
>>> I'll have to consider these and your other suggestions after I have
>>> given up on compressing the file. If I could compress it, I won't
>>> consider further reductions necessary.
>>
>> While I do not see much use in compression,
>> integer math is fun,
>> so if you want it, try to compress/decompress to/from base 36,
>> using the functions Javascript has in store,
>> toString() and parseInt():
>>
>> <script type="text/javascript">
>>
>> dateCompression(19130101);
>> dateCompression(20131228);
>>
>> function dateCompression(d) {
>>         document.write(d + ' [original number]<br>');
>>     var substrac = 19500000;
>>     d = d - substrac;
>>     var dCompressed = d.toString(36).toUpperCase();
>>         document.write(dCompressed + ' [string base 36]<br>');
>>     var dNew = parseInt(dCompressed,36) + substrac;
>>         document.write(dNew + ' [reconstructed number]<br><br>');
>> };
>>
>> </script>
>>
>> The number dnew is in binary
>> expressed as a decimal string by document.write(),
>> while the base 36 is a string by itself.
>>
>> The inputparameter d can be a number or string, try:
>>
>> dateCompression('19130101');
>
> As I said elsewhere, eventually I may consider eliminating the date
> altogether. I am wondering, however, if I could compress the planetary
> positions, which can be expressed as integer minutes. (For example,
> 17c22 equals (((c-a)*30) + 17) * 60 + 22, where c-a = 2.) How much could
> I save compressing these?
>
> emf
>

I still can't see what "17c22" means.
- "c" as a digit?
- where do the variables a and c come from?
- where do the constants 30 and 60 come from?

Nevertheless, "17c22" seems to be an integer
and the value seems to change only a bit from row to row,
so ...

Original version of ephem:
   1900-01-01 --> 12345
   1900-01-02 --> 12348
   1900-01-03 --> 12347
   1900-01-04 --> 12349

Saving bytes version of ephem:
ephem only contains the difference to the first day of then month:
   1900-01-01 --> 0
   1900-01-02 --> 3
   1900-01-03 --> 2
   1900-01-04 --> 4
an extra table month_base:
   1900-01 --> 12345
calculating the value of e.g. 1900-01-04:
   12345 + 4 --> 12349

Saving more bytes but slower version:
ephem only contains the difference to the preceding day:
   1900-01-01 --> 0
   1900-01-02 --> 3
   1900-01-04 --> -1
   1900-01-04 --> 2
an extra table month_base:
   1900-01 --> 12345
calculating the value of e.g. 1900-01-04:
   12345 + 3 + -1 + 2 --> 12349

Storing the differences inside table ephem for 5 planets:
- you can use an integer with 6 bits for every planet
   32 values = range 0 .. 31 or e.g. -10 .. 21
- you can follow the advice of Evertjan using 36-based numbers
   and store the values of 5 planets in a five char string
   36 values = range 0 .. 36 or e.g. -10 .. 26
- if this range isn't enough you may write your own
   n_based_digit-function with e.g. ...
   ... n ~  90 // printables of ascii-7
   ... n ~ 190 // printables of latin-1

Storage required for 5 char version of ephem:
60,000 × ( 5 + 2 + 1 ) = 480,000

Storage required for month_base with integers:
5 × 5,000 × ( 10 + 1 ) = 275,000
This size may be decreased by ...
... e.g. using 36 based numbers
... calculating month_base at run time with an extra table:
     month_base := year_base + month_diff

But I fear you will always have a storage size of some 100 kB's,
imho to much for an online program,
so you should still reflect about calculating values like
"17c22" on run time instead of storing them in a table.

Wolfgang

-- 
http://wzwz.de/mail

---
Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv.
http://www.avast.com

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web