Re: [dev] sbase: ed
Whoops, I withdraw my complaint. Should have checked the basics before I talked. This is a packaging error. Sorry to waste your time and mine. Regards, spaceman
Re: [dev] sbase: ed
> Hi,
Hi Spaceman,
> When compiled with musl-gcc (latest) on Slackware 14.2 this:
>
> static void
> dowrite(const char *fname, int trunc)
> {
> …
> printf("%zu\n", bytecount);
> }
>
> does not work for me (it outputs a blank line). Given my rudimentary
> knowledge of C and looking up on stackoverflow this does work.
Could you give the command you're passing to ed so we can reproduce the
issue?
> static void
> dowrite(const char *fname, int trunc)
> {
> …
> printf("%lu\n", (unsigned long) bytecount);
> }
>
> Apparently '%zu' is not very portable (limited to C99).
%zu is very portable (as is C99).
[dev] sbase: ed
Hi,
When compiled with musl-gcc (latest) on Slackware 14.2 this:
static void
dowrite(const char *fname, int trunc)
{
…
printf("%zu\n", bytecount);
}
does not work for me (it outputs a blank line). Given my rudimentary
knowledge of C and looking up on stackoverflow this does work.
static void
dowrite(const char *fname, int trunc)
{
…
printf("%lu\n", (unsigned long) bytecount);
}
Apparently '%zu' is not very portable (limited to C99).
Regards,
spaceman
Re: [dev] [sbase] [ed] A couple of notes
On 2020-03-22, Hiltjo Posthuma wrote: > Maybe it's an idea to just place issues in a TODO file in the repository? That's a good idea, thanks. I added a section with the issues reported by Cág, some existing items from ed.c, and a few others I have noticed.
Re: [dev] [sbase] [ed] A couple of notesy
Hi, As the original author of ed I have to apologize about this kind of errors. I didn;t have so much time to finalize it, and there is a list of known bugs in the header of the file. I would recomend to add new known bugs to the the list and them let to new people to fix them. I think the code of ed is very simple and hacking it is very easy, and new comers can go to fix them. As an usual user of ed I can try to fix some of them, but I am very busy lately, but with some help I am pretty sure that we can improve ed a lot and solve a lot of these problems, but they should be stored in the list of known bugs in the header and having only one place of known bugs. Roberto.
Re: [dev] [sbase] [ed] A couple of notes
Michael Forney wrote: > Sometimes people just don't have the time to investigate the issue and > come up with a fix. It could even be that the fix involves more > complex restructuring of the rest of the code. Hello Michael, Thanks for understanding. There's definitely a lack of time on my side these days. It took a couple of days definitely to simply come up with the email. On the first issue the mechanism of printing the number of bytes, from what I understand, is different from that of the 'r' command, isn't it? I can think of a couple of solutions, but without writing any code, what do you think is the correct one? Thanks again. Have a good evening. -- caóc
Re: [dev] [sbase] [ed] A couple of notes
On Sat, Mar 21, 2020 at 05:01:05PM -0700, Michael Forney wrote: > On 2020-03-21, Hiltjo Posthuma wrote: > > What kind of tracker? > > Did you see my other reply? > https://lists.suckless.org/dev/2003/33827.html > I didn't see it. > >I think discussions of suckless projects should stay > > on the mailinglist and/or IRC, not an external bugtracker or something. > > Would suckless.org consider hosting a todo.sr.ht instance? > No > > Have you tried sending the issues to the maintainer or gently bumping it? > > I am the maintainer, so that wouldn't help much. > Yes I know, I was confused with ubase. Dimitry is the maintainer there. -- Kind regards, Hiltjo
Re: [dev] [sbase] [ed] A couple of notes
On Sat, Mar 21, 2020 at 02:59:12PM -0700, Michael Forney wrote: > On 2020-03-17, Hiltjo Posthuma wrote: > > Where is the patch? > > I know it's contrary to the opinion of a lot of people here, but > personally, I have no issue with bug reports without a patch. > Sometimes people just don't have the time to investigate the issue and > come up with a fix. It could even be that the fix involves more > complex restructuring of the rest of the code. > > If the choice is between no patch, or no bug report at all, I would > definitely prefer no patch. I'd like to at least be aware of places > where sbase is non-conforming or buggy. I myself created > https://todo.sr.ht/~mcf/sbase a while ago so I could keep track of > issues that I found and have not gotten around to fixing. > > Of course supplying a patch should be highly encouraged, and if there > is no patch the issue might not get fixed quickly, or at all, > depending on its severity. > Hi, I agree, it should be encouraged. I don't think its a good idea to use external trackers for people to submit to. Bypassing the mailinglist and the community development aspect. It should be kept on suckless. Maybe it's an idea to just place issues in a TODO file in the repository? -- Kind regards, Hiltjo
Re: [dev] [sbase] [ed] A couple of notes
On Sat, 21 Mar 2020 14:59:12 -0700 Michael Forney wrote: Dear Michael, > I know it's contrary to the opinion of a lot of people here, but > personally, I have no issue with bug reports without a patch. > Sometimes people just don't have the time to investigate the issue and > come up with a fix. It could even be that the fix involves more > complex restructuring of the rest of the code. > > If the choice is between no patch, or no bug report at all, I would > definitely prefer no patch. I'd like to at least be aware of places > where sbase is non-conforming or buggy. I myself created > https://todo.sr.ht/~mcf/sbase a while ago so I could keep track of > issues that I found and have not gotten around to fixing. > > Of course supplying a patch should be highly encouraged, and if there > is no patch the issue might not get fixed quickly, or at all, > depending on its severity. I think there's a fine line between people kindly reporting problems without providing patches (as they have no time) and people demanding features or having problems fixed without providing patches. The bug tracker discussion pops up every once in a while. The opinions here are mixed. With best regards Laslo
Re: [dev] [sbase] [ed] A couple of notes
On 2020-03-21, Hiltjo Posthuma wrote: > What kind of tracker? Did you see my other reply? https://lists.suckless.org/dev/2003/33827.html >I think discussions of suckless projects should stay > on the mailinglist and/or IRC, not an external bugtracker or something. Would suckless.org consider hosting a todo.sr.ht instance? > Have you tried sending the issues to the maintainer or gently bumping it? I am the maintainer, so that wouldn't help much.
Re: [dev] [sbase] [ed] A couple of notes
On 2020-03-17, Hiltjo Posthuma wrote: > Where is the patch? I know it's contrary to the opinion of a lot of people here, but personally, I have no issue with bug reports without a patch. Sometimes people just don't have the time to investigate the issue and come up with a fix. It could even be that the fix involves more complex restructuring of the rest of the code. If the choice is between no patch, or no bug report at all, I would definitely prefer no patch. I'd like to at least be aware of places where sbase is non-conforming or buggy. I myself created https://todo.sr.ht/~mcf/sbase a while ago so I could keep track of issues that I found and have not gotten around to fixing. Of course supplying a patch should be highly encouraged, and if there is no patch the issue might not get fixed quickly, or at all, depending on its severity.
Re: [dev] [sbase] [ed] A couple of notes
On Sat, Mar 21, 2020 at 03:02:04PM -0700, Michael Forney wrote: > On 2020-03-17, Cág wrote: > > There are a couple things I've come across the > > sbase's version of ed: > > 1. w doesn't print the byte count. Suppose a sample > > ed session (using P to distinguish my input from ed's > > output): > > % ed > > P > > *a > > milk > > bread > > eggs > > meat > > veggies > > bananas > > apples > > . > > *w list > > *q > > % > > 2. I guess using ed for huge files is not really a good > > idea, however the sbase ed cannot open a 750MiB 3.5m lines > > CSV file, while the GNU version can. Probably has to do > > with the limits set. > > > > As always, I'm very pleased working with sbase and want to > > thank everybody responsible for making it. > > Hi Cág, > > Thanks for the bug reports. As Hiltjo said, it would be very helpful > if you could supply a patch for these issues. I think at least the > first one should be pretty easy to fix. > > If not, feel free to use the tracker I mentioned in my other reply to > make sure these issues are not forgotten. > Hi, What kind of tracker? I think discussions of suckless projects should stay on the mailinglist and/or IRC, not an external bugtracker or something. Have you tried sending the issues to the maintainer or gently bumping it? Thanks, -- Kind regards, Hiltjo
Re: [dev] [sbase] [ed] A couple of notes
On 2020-03-17, Cág wrote: > There are a couple things I've come across the > sbase's version of ed: > 1. w doesn't print the byte count. Suppose a sample > ed session (using P to distinguish my input from ed's > output): > % ed > P > *a > milk > bread > eggs > meat > veggies > bananas > apples > . > *w list > *q > % > 2. I guess using ed for huge files is not really a good > idea, however the sbase ed cannot open a 750MiB 3.5m lines > CSV file, while the GNU version can. Probably has to do > with the limits set. > > As always, I'm very pleased working with sbase and want to > thank everybody responsible for making it. Hi Cág, Thanks for the bug reports. As Hiltjo said, it would be very helpful if you could supply a patch for these issues. I think at least the first one should be pretty easy to fix. If not, feel free to use the tracker I mentioned in my other reply to make sure these issues are not forgotten.
Re: [dev] [sbase] [ed] A couple of notes
On Tue, Mar 17, 2020 at 11:25:25AM -0400, Cág wrote: > I must admit I only use ed(1) (of sbase) these days. > It has been like this for a year or so. > > There are a couple things I've come across the > sbase's version of ed: > 1. w doesn't print the byte count. Suppose a sample > ed session (using P to distinguish my input from ed's > output): > % ed > P > *a > milk > bread > eggs > meat > veggies > bananas > apples > . > *w list > *q > % > 2. I guess using ed for huge files is not really a good > idea, however the sbase ed cannot open a 750MiB 3.5m lines > CSV file, while the GNU version can. Probably has to do > with the limits set. > > As always, I'm very pleased working with sbase and want to > thank everybody responsible for making it. > > Cheers > > -- > caóc > Where is the patch? -- Kind regards, Hiltjo
[dev] [sbase] [ed] A couple of notes
I must admit I only use ed(1) (of sbase) these days. It has been like this for a year or so. There are a couple things I've come across the sbase's version of ed: 1. w doesn't print the byte count. Suppose a sample ed session (using P to distinguish my input from ed's output): % ed P *a milk bread eggs meat veggies bananas apples . *w list *q % 2. I guess using ed for huge files is not really a good idea, however the sbase ed cannot open a 750MiB 3.5m lines CSV file, while the GNU version can. Probably has to do with the limits set. As always, I'm very pleased working with sbase and want to thank everybody responsible for making it. Cheers -- caóc
