Re: [DNG] High level language primitives [ was Please keep 32-bits alive]

[Didier Kryn]

Le 29/07/2017 à 09:41, Olaf Meeuwissen a écrit :

Hi,

Didier Kryn writes:


  In an ideal word, software would have

  - maximum performance
  - minimum resource usage
  - minimum of dangerous bugs

In an ideal world, software would have *no* bugs ;-)

And zero resource usage and zero development time ;-)




  - easy maintainability
  - fast development
  - what else?

Software would be Free as in freedom.


Yep, I forgot that point. And also documentation as mentionned by Ron.

Cheers.
Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] High level language primitives [ was Please keep 32-bits alive]

[Ron]

On Sat, 29 Jul 2017 16:41:01 +0900
Olaf Meeuwissen  wrote:

> >  In an ideal word, software would have
> >
> >  - maximum performance
> >  - minimum resource usage
> >  - minimum of dangerous bugs  
> 
> In an ideal world, software would have *no* bugs ;-)
> 
> >  - easy maintainability
> >  - fast development
> >  - what else?  
> 
> Software would be Free as in freedom.

Documentation ?
 
Cheers,
 
Ron.
-- 
 The difference between science and the fuzzy subject
 is that science requires reasoning while those other
 subjects merely require scholarship.
   -- Robert A. Heinlein 

   -- http://www.olgiati-in-paraguay.org --
 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] High level language primitives [ was Please keep 32-bits alive]

[Olaf Meeuwissen]

Hi,

Didier Kryn writes:

>  In an ideal word, software would have
>
>  - maximum performance
>  - minimum resource usage
>  - minimum of dangerous bugs

In an ideal world, software would have *no* bugs ;-)

>  - easy maintainability
>  - fast development
>  - what else?

Software would be Free as in freedom.
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Softwarehttps://my.fsf.org/donate
 Join the Free Software Foundation  https://my.fsf.org/join
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] High level language primitives [ was Please keep 32-bits alive]

[Didier Kryn]

Le 27/07/2017 à 16:18, Enrico Weigelt, metux IT consult a écrit :

On 27.07.2017 08:22, Didier Kryn wrote:


At first glance at least, it means that file offsets are managed in the
kernel or VFS


Of course they are. That's required for any sane multiprocessing
implementation. And some files/devices don't even have the notion
of a current position (IOW: not seekable at all).

> but they can be bypassed by pwrite(). AFAIR pwrite()

doesn't change the "current" file offset; it simply ignores and bypasses
it, which isn't exactly what your example does.


Yes, that's an separate syscall for direct access. Simple streams
(eg. tty's, pipes, stream sockets, etc) usually don't support it.


Using unistd's read() and write() in C means you are dealing with low
level issues; otherwise why would you bother with the complexity it
introduces - not only you need to deal with buffering but also with
retries when interrupted by signals.


Usually you wanna care about signals - they actually mean something.
The ansi stream functions might or might not make it easier - depending
on your actual usecase. If you care about performance, you likely
don't wanna use them. 


In an ideal word, software would have

- maximum performance
- minimum resource usage
- minimum of dangerous bugs
- easy maintainability
- fast development
- what else?

It's impossible to reach all these targets in the same time; 
therefore the first design decision is which compromise between these is 
the target. This implies choices in the organization of the program, the 
language(s) to use, and possibly the programmer(s). I'm sure you know 
this very well :-)


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] High level language primitives [ was Please keep 32-bits alive]

[Enrico Weigelt, metux IT consult]

On 27.07.2017 08:22, Didier Kryn wrote:


At first glance at least, it means that file offsets are managed in the
kernel or VFS


Of course they are. That's required for any sane multiprocessing
implementation. And some files/devices don't even have the notion
of a current position (IOW: not seekable at all).

> but they can be bypassed by pwrite(). AFAIR pwrite()

doesn't change the "current" file offset; it simply ignores and bypasses
it, which isn't exactly what your example does.


Yes, that's an separate syscall for direct access. Simple streams
(eg. tty's, pipes, stream sockets, etc) usually don't support it.


Using unistd's read() and write() in C means you are dealing with low
level issues; otherwise why would you bother with the complexity it
introduces - not only you need to deal with buffering but also with
retries when interrupted by signals.


Usually you wanna care about signals - they actually mean something.
The ansi stream functions might or might not make it easier - depending
on your actual usecase. If you care about performance, you likely
don't wanna use them.

--mtx

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] High level language primitives [ was Please keep 32-bits alive]

[Didier Kryn]

Le 26/07/2017 à 22:00, Christopher Clements a écrit :


Wouldn't this work? (no error checking of course XD)

   off_t lseek(int fd, off_t offset, int whence);
   ssize_t write(int fd, const void *buf, size_t count);
  ssize_t pwrite(int fd, const void *buf, size_t count, off_t 
offset) {

   lseek(fd, offset, SEEK_SET);
   return write(fd, buf, count);
   }

I looked at the source code of Musl libc. Actually both write() and 
pwrite() are simple wrappers to... a general-purpose system-call 
wrapper. The second simply has one more argument. I didn't dig further. 
At first glance at least, it means that file offsets are managed in the 
kernel or VFS but they can be bypassed by pwrite(). AFAIR pwrite() 
doesn't change the "current" file offset; it simply ignores and bypasses 
it, which isn't exactly what your example does.


But the discussion was about low-level vs high-level programming. 
Using unistd's read() and write() in C means you are dealing with low 
level issues; otherwise why would you bother with the complexity it 
introduces - not only you need to deal with buffering but also with 
retries when interrupted by signals.


Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng