> I briefly considered this, but I think we should rather go for the
> opposite: let the XSLT translator take files as input. If directory
> input is desired, it can always be set on top of unxml.
That is probably a better solution, if the xslt translator presents a
file as output, giving it a dir
Hi,
On Thu, Apr 07, 2011 at 09:09:35PM +0100, Michael Walker wrote:
> > I don't think the XSLT translator should present a directory tree as
> > output. Nothing in XSLT requires the output to be XML.
>
> Aha, I had a feeling I was misunderstanding something somewhere. In
> that case, xslt would
Hi,
On Thu, Apr 07, 2011 at 01:46:02PM +0100, Michael Walker wrote:
> * Read support in unxmlfs
> unxmlfs takes an xmlfs-compatible directory tree and turns it
> into an XML file, thus reading will be done via libtrivfs, with no
> write support (I see no need/use for that).
I do.
The GSo
> Well, if you need the exact same code, this is a pretty good indication
> that it probably shouldn't be in the XSLT translator at all... Working
> on top of a directory tree would only make sense if it would actually
> use the provided structure directly, rather than first serializing it.
>
> Or
Hi,
On Wed, Apr 06, 2011 at 03:43:15PM +0100, Michael Walker wrote:
> I did originally just plan to do xmlfs, but then I realised that most
> of the nontrivial code in the xslt translator and in unxmlfs would be
> the same - the directory-tree-to-XML parser, which shouldn't really be
> too hard.
> I did originally just plan to do xmlfs, but then I realised that most
> of the nontrivial code in the xslt translator and in unxmlfs would be
> the same - the directory-tree-to-XML parser, which shouldn't really be
> too hard. The only other nontrivial part of the xslt code is the
> libnetfs-base
> That's always a good start! Where is this repository that your patch is
> against?
http://cvs.savannah.gnu.org/viewvc/xmlfs/?root=hurdextras
> Your editor / mailer broke the lines, so this patch won't even apply.
> Either you instruct your editor / mailer, or let git send-email take care
> of
> So the idea is that one would launch an XSLT translator, with a XSLT
> style sheet as input, on top of an xmlfs directory, and the result would
> be a file representing the output of the XSLT processor?
Yes, that's what I was thinking. Though, being able to run it on top
of an XML file should be
olafbuddenha...@gmx.net, le Tue 05 Apr 2011 22:24:57 +0200, a écrit :
> So the idea is that one would launch an XSLT translator, with a XSLT
> style sheet as input, on top of an xmlfs directory,
No, I'd rather say on top of an xml file.
Samuel
On Sun, Apr 03, 2011 at 02:10:33AM +0200, Samuel Thibault wrote:
> Michael S. Walker, le Sun 03 Apr 2011 00:30:32 +0100, a écrit :
> > What's the correct way to produce a patch? I'm using git for version
> > control (if that's relevant).
>
> Then git diff.
No, git format-patch is much better.
-
Hi,
On Sun, Apr 03, 2011 at 12:30:32AM +0100, Michael S. Walker wrote:
> On Fri, 1 Apr 2011 19:41:28 +0200 wrote:
> > > * Support for XSLT transformations
> >
> > Not sure how that would fit?...
>
> It was an idea proposed in the TODO file, though that might be better
> as a separate transla
Hallo!
Olaf surely will already be drafting the email to introduce you to the
proper Git patch submissing wonders (short: have a local branch, better
yet, a separte branch per topic, commit logically independent patches in
there (for example, adding a .gitignore file is different from fixing
compi
The below patch monitors the backing store for changes (if it's a
separate file rather than the underlying node) and updates the
presented directory hierarchy when a change is detected.
diff --git a/Makefile b/Makefile
index d646475..747739e 100644
--- a/Makefile
+++ b/Makefile
@@ -3,15 +3,15 @@ C
The below patch fixes all compiler warnings. It's quite long as I use
a lot of warning flags (habit from when I was working on my own kernel
project):
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000..e20fc66
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,2 @@
+*.o
+xmlfs
diff --
Michael S. Walker, le Sun 03 Apr 2011 00:30:32 +0100, a écrit :
> On Fri, 1 Apr 2011 19:41:28 +0200
> wrote:
> > On Tue, Mar 29, 2011 at 10:57:44PM +0100, Michael Walker wrote:
> >
> > > * Fix all gcc warnings [done]
> >
> > Send the patch(es) :-)
>
> What's the correct way to produce a patch?
On Fri, 1 Apr 2011 19:41:28 +0200
wrote:
> Hi,
>
> On Tue, Mar 29, 2011 at 10:57:44PM +0100, Michael Walker wrote:
>
> > * Fix all gcc warnings [done]
>
> Send the patch(es) :-)
What's the correct way to produce a patch? I'm using git for version
control (if that's relevant).
> > * Suppo
Hi,
On Tue, Mar 29, 2011 at 10:57:44PM +0100, Michael Walker wrote:
> * Fix all gcc warnings [done]
Send the patch(es) :-)
> * Support for XSLT transformations
Not sure how that would fit?...
The rest makes sense as far as I can tell; so I hope to see a good
application soon :-)
-antrik-
Michael Walker, le Tue 29 Mar 2011 22:57:44 +0100, a écrit :
> Finally, even if this doesn't get picked as a GSoC task (after I send
> off my application), I still intend to do this over the summer to
> better learn Hurd programming, and so either way there will be an
> improved xmlfs this year :)
Hi,
I'd like to apply to work on xmlfs for GSoC this summer. I've been
going through the code over the past few days and working on it a bit,
and have come up with a list of things to implement:
* Fix all gcc warnings [done]
This was really just so I'd be able to see which
19 matches
Mail list logo
