Whats more, the VM I/O abstraction is already hiding details of its
underlying platforms.
Having another I/O abstraction across multiple VMs sounds like the
Fantom Programming Language approach which pushes a unique API across
different VM implementations.
AFAIK the Clojure approach is more about
On Sat, Mar 10, 2012 at 9:41 PM, Brian Goslinga wrote:
> There is a trade off here. If you want to be very portable you'll end up
> with something like the CL path API because you need logicals and file
> revisions to really support VMS, for example.
>
In a former life I spent more time than I no
On Saturday, March 10, 2012 7:57:59 AM UTC-6, lpetit wrote:
>
>
>
> 2012/3/10 Brian Goslinga
>
>> On Mar 8, 3:12 pm, cej38 wrote:
>> > This is a NOOB question.
>> >
>> > Would it be possible to write a library that could do IO without
>> > resorting to the underlying VM?
>> I would be suspiciou
2012/3/10 Brian Goslinga
> On Mar 8, 3:12 pm, cej38 wrote:
> > This is a NOOB question.
> >
> > Would it be possible to write a library that could do IO without
> > resorting to the underlying VM?
> I would be suspicious of a cross-implementation wrapper. You'll
> probably end up with something
On Mar 8, 3:12 pm, cej38 wrote:
> This is a NOOB question.
>
> Would it be possible to write a library that could do IO without
> resorting to the underlying VM?
I would be suspicious of a cross-implementation wrapper. You'll
probably end up with something as awful as the Common Lisp path API.
Wor
Possible to do I/O without any interop ever being called? No.
Possible to define a standard I/O abstraction that hides the details of the
underlying VM? Yes. But difficult. I/O is a leaky abstraction at the best
of times.
-S
--
You received this message because you are subscribed to the Google
>Should there be a standard Clojure IO API that each flavor of Clojure would
>implement?
You are correct. This is more of what my question should have been.
I do NOT want to restrict myself to a particular platform.
--
You received this message because you are subscribed to the Google
Groups
On Thu, Mar 8, 2012 at 4:12 PM, cej38 wrote:
> Would it be possible to write a library that could do IO without
> resorting to the underlying VM?
What do you mean by that? Do you want to restrict yourself to a
particular platform?
I think a more prudent question would be: Should there be a stand
This is a NOOB question.
Would it be possible to write a library that could do IO without
resorting to the underlying VM?
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts fr
> > I wonder if it would be a good idea to include a clojure.io
> > namespace in Clojure itself.
+1.
> > read-lines was left out since ...
On the basis that it's less painful to add new stuff in later than to
remove stuff I agree that erring on the side of caution
Stuart Sierra writes:
> On Dec 31 2009, 9:58 pm, Phil Hagelberg wrote:
>> I wonder if it would be a good idea to include a clojure.io
>> namespace in Clojure itself. I've mentioned the idea a few times on IRC,
>> and people seemed to be very much in favour.
>
>
On Jan 1, 4:34 pm, Phil Hagelberg wrote:
> Sean Devlin writes:
> > 1. I'd recommend adding support for general unix file utilities.
> > I've written some of them myself, and you can review/borrow/steal code
> > from here:
>
> >http://github.com/francoisdevlin/devlinsf-clojure-utils/blob/master/s
My 2c.
In any clojure.io library, make sure none of the warts that are planned to
be fixed in NIO2 are codified.
JDK7 includes work on Path, large directory traversal, event notifications
etc.
See http://java.sun.com/developer/technicalArticles/javase/nio/
Alexander
2010/1/1 Phil Hagelberg
Kevin Downey writes:
> (io/read [:lines :from :as p]
>(do-stuff-with-a-string p))
>
> (io/read [:lines :from ]) ;no :as binding or body, results
> in a lazy-seq of lines
And it's important to specify whether "p" in the former or the head item
in the sequence in the latter remain valid after
I think something more abstract would be good. A function or macro
where you pass it an "IO Spec" and it takes care of all the class
stuff.
(io/read [:bytes :from :as p]
(do-stuff-with-a-byte p))
(io/read [:lines :from :as p]
(do-stuff-with-a-string p))
(io/read [:lines :from ]) ;no :as b
Sean Devlin writes:
> 1. I'd recommend adding support for general unix file utilities.
> I've written some of them myself, and you can review/borrow/steal code
> from here:
>
> http://github.com/francoisdevlin/devlinsf-clojure-utils/blob/master/src/lib/sfd/file_utils.clj
These are all one-line
On Dec 31 2009, 9:58 pm, Phil Hagelberg wrote:
> I wonder if it would be a good idea to include a clojure.io
> namespace in Clojure itself. I've mentioned the idea a few times on IRC,
> and people seemed to be very much in favour.
I've considered this too, but I know Rich Hic
m, Phil Hagelberg wrote:
>
> > I've been looking over our use of contrib in our large-ish project
> > at work. About 90% of the invocations of contrib functions are
> > I/O-related.
>
> evil mutable little bastards, these files ;-)
>
> > I wonder if it w
idea to include a clojure.io
> namespace in Clojure itself.
inc
> I've prototyped this in the attached file. Most of the functions come
> from contrib's duck-streams library. I've taken everything from
> duck-streams except read-lines, file-str, make-parents, and pwd.
&
On 01.01.2010, at 03:58, Phil Hagelberg wrote:
> I welcome discussion about this proposal. Do you think it's
> necessary? Are
> there any functions we should leave out? Any others we should
> promote from
> contrib?
I am very much in favour of a clojure.io library.
I've been looking over our use of contrib in our large-ish project
at work. About 90% of the invocations of contrib functions are
I/O-related. I wonder if it would be a good idea to include a clojure.io
namespace in Clojure itself. I've mentioned the idea a few times on IRC,
and people
21 matches
Mail list logo
