How to gzipSync?

[Axel Kittenberger]

Is there some easy way to make yourself a zlib.gzipSync wrapper around
the nodes default callback/pipe interface to zlib? (Without streamline
or fibers)

Its for the server startup sequence where it generates one hugh
javascript file for the client side to download and it keeps it raw as
well gzipped in memory. It does read the files with readSyncFile etc.
So yes I want the node process to be halted until it is done. Its fine
it takes 2 seconds, so please don't argue it could do this or that in
parallel. I also do the other *Sync calls for startup. I just want to
keep that simple please.

- Axel

[Jake Verbaten]

An asynchronous start up sequence is significantly more trivial to implement then writing a wrapper for gzipSync

- Axel

--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

[Arnout Kazemier]

Or you could just add your server.listen in the callback of the gzip and you achieve the same result.

A delayed startup of your server, until the shit is gziped

[Oliver Leics]

Am also interested in some easy way.
What are the options?

BTW: Please, stay with the topic. It is about "how to do it" and not
about "convince me to do not this way" Thank you.

--
Oliver Leics @ G+
https://plus.google.com/112912441146721682527

[Axel Kittenberger]

Yes thank you. That's a pragmatic solution that only came to my mind after I posted. I suppose later ill have to do a more developed startup anyway when I'm utilizing a database.

[Oliver Leics]

OP governs the thread. Thats the way.. :-)

--

[dhruvbird]

Hello,

You could (at least in theory) spawn a gzip process that writes to a
FIFO* (named pipe) and then use fs.readFileSync() to read that FIFO.
Your process should block till you have completed reading in the FIFO.
Create a wrapper function to do this an you have a blocking gzip()
routine!

* Might not work on windows.

Regards,
-Dhruv.

[Tim Caswell]

I wonder why node doesn't just expose a sync version of the zlib functions.  It's not like they are performing I/O or anything. FWIW I intend to have both sync and async in luvit's zlib bindings unless there is a good reason not to.

[Jorge]

On Apr 19, 2012, at 2:35 PM, Tim Caswell wrote:

> I wonder why node doesn't just expose a sync version of the zlib functions. It's not like they are performing I/O or anything. FWIW I intend to have both sync and async in luvit's zlib bindings unless there is a good reason not to.

Did you say *sync*? Heresy!
--
Jorge.

[Ben Noordhuis]

On Thu, Apr 19, 2012 at 14:35, Tim Caswell <t...@creationix.com> wrote:
> I wonder why node doesn't just expose a sync version of the zlib functions.
> It's not like they are performing I/O or anything. FWIW I intend to have
> both sync and async in luvit's zlib bindings unless there is a good reason
> not to.

Here's why: https://github.com/joyent/node/issues/3128#issuecomment-5197171

[Bruno Jouhier]

Sync calls should only be allowed in startup sequence and in require.

Would it be possible to have a "strict async" switch that make all Sync calls throw if called outside of startup or require sequences?
This would make it easy to spot libraries that are potential perf killers.

Bruno

[Mark Hahn]

>   "strict async" switch 

+1

[Axel Kittenberger]

> Would it be possible to have a "strict async" switch that make all Sync
> calls throw if called outside of startup or require sequences?
> This would make it easy to spot libraries that are potential perf killers.

I'm not sure how the node modules system behaves if you alter required
tables, so would this work*?

var gotyou = function() { throw new Error('Evil Sync caller you!'); };
for (var k in fs) {
if (fs.hasOwnProperty(k) && k.search(/Sync$/) >= 0) { fs[k] = gotyou; }
}

*Unless something is that evil to cache the function pointers, or to
require later on. However, one could set "require" to gotyou as well
after startup.

[Oleg Efimov (Sannis)]

Latest Crockford's JSLint have an option to alert Sync functions usage.

You proposal is more complicated, I don't really think how to realize this :(

четверг, 19 апреля 2012 г., 21:46:37 UTC+4 пользователь Bruno Jouhier написал:

[Bruno Jouhier]

Would work for most but my stuff requires additional modules dynamically as it runs, to avoid polluting startup with things that may never be needed (like dev/test/maintenance functions). So, I'd need to restore the Sync functions temporarily for require. Looks like it can be done by wrapping the require hooks.

The bottom line is that require should not be sync. It does not work well if you require modules dynamically, it also makes it harder to hack require so that it loads code from something else than the local file system (a database or a RESTful service). But it is probably too late to do anything about it.

Bruno

[Isaac Schlueter]

On Thu, Apr 19, 2012 at 10:46, Bruno Jouhier <bjou...@gmail.com> wrote:
> Sync calls should only be allowed in startup sequence and in require.
>
> Would it be possible to have a "strict async" switch that make all Sync
> calls throw if called outside of startup or require sequences?
> This would make it easy to spot libraries that are potential perf killers.

npm install nosync

require("nosync")
fs.openSync("filename", "r") // <-- throws

[Axel Kittenberger]

> npm install nosync
>
> require("nosync")
> fs.openSync("filename", "r") // <-- throws

Cool. Thats why I don't buy into the argument, the Sync versions of
the un/compress API would lead to people misusing it, since it can be
inhibited as easy as you showed us.

Although I do buy into the argument, it is hardly used/requested and
for the amount of code to maintain it's not worth it and easy to
workaround with Asyncs rather than bloating the node core.

[Egor Egorov]

https://github.com/egorFiNE/node-compress-buffer

[Axel Kittenberger]

Great, I actually seen this, when I searched for a solution, but I
need gzip, not compress.

If this isn't "compress" but gzip after all, you really should change
your README to highlight this. Maybe its the age from back of the
1990s so when one read or wrote "compress" without any highlight, Its
assumed the compression algorithmn that used to be called "compress",
that is LZ77 without huffman encoding.

[Matthew Hazlett]

Just an FYI.

Geddy has a mailing list now:
https://groups.google.com/forum/?fromgroups#!forum/geddyjs