headers
ozan s yigit | 6 Apr 2006 21:24
Picon

wily 0.13.42

it lives. :)

new wily version. updated ftp://ftp.cs.yorku.ca/pub/wily/src/
and will update sourceforge later tonight.

9libs had to have a micro-version increment. it is now at 1.0.1.

These are all the interesting changes from wily 0.13.41 to
0.13.42 done by tommy Pettersson <ptp <at> lysator.liu.se>. Please
let me know if you run into trouble with any of these changes.
if you have a philosophical disagreement with any of the fixes
also let me know, and i will try to resolve it. 

thank you tommy. and thanks to derek peschel for bugging me
about configs. thank you to all those who have sent fixes in
the past, some of which is in this new version. i appreciate
the help. 

---- changes ---

Configs for 9libs and wily-9libs have been brought up-to-date
to allow 9libs compilation under Mac OS-X.

The most complicated change is with reading utf8. Multibyte utf
sequences could get split and generate two invalid runes instead
of one valid. This could happen both on file reads, if the file
was larger then the temporary read buffer, and on output events
from external processes. Wily sometimes missed to warn about
nulls when reading large files. Nulls are now replaced with
invalid runes on file reads. Wily will also warn about both
(Continue reading)

Permalink | Reply | 4 comments |
headers
ozan s yigit | 6 Apr 2006 22:59
Picon

one more thing: config

i should mention that while i upgraded config bits in wily
i did not try to clean it up; any input from autoconf/libtool
et al. experts would be welcomed. [i detest autoconf & friends
but i doubt a replacement is coming anytime soon...]

oz
Permalink | Reply | 0 comments |
headers
Ian Broster | 6 Apr 2006 23:44
Picon

Re: wily 0.13.42


> it lives. :)

Congratulations! Well done. I confirm that it compiles and runs ok for me
on debian.

I have been very lax about applying patches to my copy as they have
appeared, I have been waiting for someone else to do all the hard work and
reconcile them all together. So, I'm very pleased to have this new version.

Obviously, it has not been possible to fix all bugs this time, there are a
couple that I notice straight away. I'll include them below in the hope
that someone will manage to fix them. :-)

I notice that Debian has wily as a package. I don't know who maintains
this? Can we see a debian upgrade to this new version?

Ian

P.S. two noticeable bugs:

1. Binary files. Load a binary fily, /bin/echo for example, and Put it
again as a different filename. The two files are different.
2. Window resize: shrink a window horizonally, then expand it again.
Different algorithms are used for the proportions for the existing columsn
when skrining and expanding.

--

-- 
Ian Broster
(Continue reading)

Permalink | Reply | 3 comments |
headers
ozan s yigit | 7 Apr 2006 02:49
Picon

Re: wily 0.13.42


> 1. Binary files. Load a binary fily, /bin/echo for example, and Put it  
> again as a different filename. The two files are different.

hmm, you are right this is a yet-unfixed one. :-P i have just tried
the older version on osX and freebsd and indeed files are clobbered....

oz
Permalink | Reply | 502 comments |
headers
Gary Capell | 7 Apr 2006 03:06
Picon
Favicon

Re: wily 0.13.42

On Thu, Apr 06, 2006 at 08:49:38PM -0400, ozan s yigit wrote:
> 
> > 1. Binary files. Load a binary fily, /bin/echo for example, and Put it  
> > again as a different filename. The two files are different.
> 
> hmm, you are right this is a yet-unfixed one. :-P i have just tried
> the older version on osX and freebsd and indeed files are clobbered....

I'm not sure this is a bug we want to fix?  I'm guessing that this
is because (not surprisingly) some bits of /bin/echo aren't valid
UTF8.  To fix it we'd have to maintain two copies of the file:
the version with valid UTF, and the original version with invalid
UTF.  Actually, that just lets us replace 'Put' with a no-op,
of writing back the original data.  

What _might_ make sense is to mark a file as Read Only (or
something) when the utf parsing has made changes that will
be destructive when we write it back?

... or I could be completely misunderstanding the problem.

--

-- 
Gary Capell <gary <at> commsecure.com.au>
Permalink | Reply | 503 comments |
headers
ozan s yigit | 7 Apr 2006 04:08
Picon

Re: wily 0.13.42

Hi Gary,

i am not sure either. i think this is where years of emacs binary
patching has spoiled some of us... :)

> I'm not sure this is a bug we want to fix?  I'm guessing that this
> is because (not surprisingly) some bits of /bin/echo aren't valid
> UTF8.  To fix it we'd have to maintain two copies of the file:
> the version with valid UTF, and the original version with invalid
> UTF.  Actually, that just lets us replace 'Put' with a no-op,
> of writing back the original data.  
> 
> What _might_ make sense is to mark a file as Read Only (or
> something) when the utf parsing has made changes that will
> be destructive when we write it back?

this is an interesting idea actually. better than silent
conversion...

oz
Permalink | Reply | 3 comments |
headers
MJ Ray | 7 Apr 2006 08:27
Gravatar

Re: wily 0.13.42

"Ian Broster" <ian <at> broster.co.uk>
> I notice that Debian has wily as a package. I don't know who maintains
> this? Can we see a debian upgrade to this new version?

dpkg -s wily | grep Maintainer
Maintainer: MJ Ray (Debian) <mjr <at> debian.org>

That'll be me, then.

Upgrading will involve moving to 9libs, as I understand it.  I'd
not done that because I didn't succeed in building a version which
ran on all my machines, so I was cautious.  I'll do it Real Soon Now,
or sooner if you'll share your build notes...

Thanks,
--

-- 
MJR/slef
Laux nur mia opinio: vidu http://people.debian.org/~mjr/
Bv sekvu http://www.uk.debian.org/MailingLists/#codeofconduct
Permalink | Reply | 2 comments |
headers
Ian Broster | 7 Apr 2006 07:36
Picon

Re: wily 0.13.42


> Upgrading will involve moving to 9libs, as I understand it.  I'd
> not done that because I didn't succeed in building a version which
> ran on all my machines, so I was cautious.  I'll do it Real Soon Now,
> or sooner if you'll share your build notes...

./configure;make

:-)

Which machines didn't this work on?

Actually, both the 9libs version and the non-9libs version built "out the  
box" on debian for me.

i.

--

-- 
Ian Broster
Permalink | Reply | 1 comment |
headers
Ian Broster | 7 Apr 2006 07:57
Picon

Re: wily 0.13.42


> I'm not sure this is a bug we want to fix?  I'm guessing that this
> is because (not surprisingly) some bits of /bin/echo aren't valid
> UTF8.

I see.

However it does seem to break a rather fundamental assumption that a load  
then save will not corrupt the file.

Most text editors seem ok with binry files (presumably because the don't  
do UTF at all); despite the technical difficulties of doing so in wily, I  
think it's worth another think.

> we'd have to maintain two copies of the file:
> the version with valid UTF, and the original version with invalid
> UTF.

Is there no way to have a raw representation in memory and a best-effort  
UTF8 render/manipulation?

i.

--

-- 
Ian Broster
Permalink | Reply | 2 comments |
headers
Gary Capell | 7 Apr 2006 09:04
Picon
Favicon

Re: wily 0.13.42

On Fri, Apr 07, 2006 at 07:57:11AM +0200, Ian Broster wrote:
> 
> >I'm not sure this is a bug we want to fix?  I'm guessing that this
> >is because (not surprisingly) some bits of /bin/echo aren't valid
> >UTF8.
> 
> I see.
> 
> However it does seem to break a rather fundamental assumption that a load  
> then save will not corrupt the file.

Agreed.  Hence the "ReadOnly" suggestion.

> Most text editors seem ok with binry files (presumably because the don't  
> do UTF at all); despite the technical difficulties of doing so in wily, I  
> think it's worth another think.
> 
> >we'd have to maintain two copies of the file:
> >the version with valid UTF, and the original version with invalid
> >UTF.
> 
> Is there no way to have a raw representation in memory and a best-effort  
> UTF8 render/manipulation?

Of course there's a way (probably _lots_ of ways) to do it.
The questions are:
 * do any of the ways have negligible impact on code complexity
	and efficiency (i.e. not requiring duplicate work on
	two copies of buffers)?
(Continue reading)

Permalink | Reply | 1 comment |

Gmane