zsh-workers
 help / color / mirror / code / Atom feed
* endianness of wordcode
@ 2000-03-23 21:04 Peter Stephenson
  2000-03-25 20:39 ` Bart Schaefer
  0 siblings, 1 reply; 5+ messages in thread
From: Peter Stephenson @ 2000-03-23 21:04 UTC (permalink / raw)
  To: Zsh hackers list

I'm a little doubtful about the necessity of having doubled wordcode files
for different endianness.  It's only useful when sharing files across
heterogeneous networks --- you wouldn't distribute wordcode files, you'd
compile them in situ (or at least I would).  I wonder whether it would be
better always to dump in the native format, check if the order is swapped
when reading, and if so swap it back on the fly.  That's a fairly trivial
operation compared with all the rest of the stuff zsh is going to be doing
with the extracted code.

In fact, the code I stole as the basis for the pattern-matching equivalent
of wordcode explicitly reconstructs integers by shifting and or'ing,
probably without even the intention of making it machine-independent since
the compiled patterns were for internal use.

I think the zcompile documentation, and maybe other places where wordcode
is mentioned, could be friendlier: it introduces the (non-existent?) word
`wordcode' with no explanation, and you really don't even need to know that
it exists, only that there is a black box which produces versions of
functions that load faster and maybe save memory.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>


^ permalink raw reply	[flat|nested] 5+ messages in thread
* Re: endianness of wordcode
@ 2000-03-27  8:32 Sven Wischnowsky
  0 siblings, 0 replies; 5+ messages in thread
From: Sven Wischnowsky @ 2000-03-27  8:32 UTC (permalink / raw)
  To: zsh-workers


Bart Schaefer wrote:

> On Mar 23,  9:04pm, Peter Stephenson wrote:
> } Subject: endianness of wordcode
> }
> } I'm a little doubtful about the necessity of having doubled wordcode files
> } for different endianness.  [...]  I wonder whether it would be
> } better always to dump in the native format, check if the order is swapped
> } when reading, and if so swap it back on the fly.
> 
> At one point I think the wordcode files were always mmap'd, which meant
> they couldn't be unswapped.  Now that Sven has written the code to read
> the files when mmap isn't available, it should be possible to recognize
> swapped files and switch to reading them -- but it'll be a little messy,
> as swapped-ness won't be detected until after the file is mmap'd.

No, this can be decided by reading only the header, which is done
before mmap'ing a file.

I'm not sure if we want to get rid of the endianess stuff, though. The 
original request for it came because we were thinking about globally
installed wordcode files. I wasn't too hapy with that at the time, but 
*if* global wordcode files are a good idea, we should make them
contain both versions. If we don't do that people may think that the
files are mapped but they aren't, just because they are on the wrong
architecture.

(I'll come back to the other things later...)

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


^ permalink raw reply	[flat|nested] 5+ messages in thread
* Re: endianness of wordcode
@ 2000-03-27 11:43 Sven Wischnowsky
  2000-03-27 16:28 ` Bart Schaefer
  0 siblings, 1 reply; 5+ messages in thread
From: Sven Wischnowsky @ 2000-03-27 11:43 UTC (permalink / raw)
  To: zsh-workers


Bart Schaefer wrote:

> ...
> 
> } I think the zcompile documentation, and maybe other places where wordcode
> } is mentioned, could be friendlier [...]
> 
> Yes.

Thanks, Bart.

> We'd also discussed changing -r/-m to -R/-M and changing -M to -m, but this
> patch doesn't do that yet.

I haven't done that yet either, because I fear I have to do some more
with this yet.

> Sven, please check the accuracy of my edits to func.yo. 

They are correct. At least that's how it should work and seems to work 
for me.

Now...

> In particular
> I'm not sure how to explain what happens if you do
> 
> 	zcompile -c foo foo bar frob ding
> 	fpath=($PWD)
> 	autoload foo
> 	foo

I don't understand what you mean here. If foo is already defined, the
autoload won't change that and you just get that executed. If foo is
unfunction'ed before the autoload, it loads foo.zwc and executes foo
just as expected. At least for me. What am I missing?

> And I'm even more confused by
> 
> 	zcompile -c foo -k foo bar frob ding
> 	fpath=($PWD)
> 	autoload foo
> 	foo
> 
> which first executes "foo" successfully and then prints
> 
> 	foo:3: foo: function not defined by file
> 
> leaving "foo" as an undefined (but marked autoloaded) function.

Here at least `foo' was already defined, right. This is a problem I
hadn't thought about. If we save it to be loaded ksh-style, the init
code originally surrounding the function definition (if there was any) 
is, of course, already deleted. So, the best attempt we could do is to 
put the body of the function in a `foo() { body }' and save that (I
mean, zcompile would do that, the definition of foo in the current
shell wouldn't be changed).

But this is a bit ugly, too. Maybe the user just wasn't aware of this
effect and would have preferred a warning. So maybe we should just do
that. Note also, that for ksh-style autoloaded function that aren't
loaded yet, the whole contents of the definition file is put into the
wordcode file (i.e. one gets different results depending on whether
the function is already loaded or not).

Or maybe we should first try to find the original file defining the
function, if we find one, write that into the wordcode file (but if
foo had been changed in the meanwhile, the changes would be lost, hm), 
if not, do the `foo() { body }' trick.

Hrm. Dunno. I seem to prefer the solution that just prints an error
message and doesn't even try to create the wordcode file in such a
case.

Help, please.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


^ permalink raw reply	[flat|nested] 5+ messages in thread
end of thread, other threads:[~2000-03-27 16:28 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-03-23 21:04 endianness of wordcode Peter Stephenson
2000-03-25 20:39 ` Bart Schaefer
2000-03-27  8:32 Sven Wischnowsky
2000-03-27 11:43 Sven Wischnowsky
2000-03-27 16:28 ` Bart Schaefer

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).