Re: [Haskell-cafe] ANN: unix-2.4.0.0 additional POSIX real time support

[Don Stewart-2]

vigalchin:

>    Hello,
>
>          Additional POSIX realtime (POSIX 1003.1b) support has been added:
>
>    1) MQueue.hsc - POSIX message queues
>
>         Supported FFI bindings for:
>    
>              - mq_open
>
>              - mq_close
>
>              - mq_unlink
>
>              - mq_getattributes
>
>              - mq_setattributes
>
>              - mq_send
>
>          Not yet supported bindings:
>
>              - mq_rcv .. still debugging a mysterious problem
>
>              - mq_notify - will support when asynchronous I/O is implemented
>
>    2) RTsched.hsc - real time scheduling
>
>          Supported bindings for:
>
>                - sched_yield
>
>                - sched_get_param
>
>                - sched_set_param
>
>                - sched _get_scheduler
>
>                - sched_set_scheduler
>
>                - sched_get_priority_min
>    
>                - sched_get_priority_max    
>
>          Unsupported currently:
>
>                 - sched_rr_get_interval - still looking for the TimeSpec data
>    type in order to get "peek"  working
>
>    3) Files.hsc
>
>               Added bindings for:
>
>                     - fsync
>
>                     - fdatasync    
>
>    I am new to Haskell but would like to make a lot of contributions to
>    insure Haskell success in the marketplace (of ideas ;^)).  I apologize for
>    any glitches and look for feedback.

Very interesting!

However... this library is a core package, and maintained by
libraries@..., so you should not release it yourself.

Instead, submit your patches to libraries@ for inclusion, following the
patch submission guide here:

    http://haskell.org/haskellwiki/How_to_write_a_Haskell_program

Where the patches will be tested on other unix platforms, and then
encorporated into the main 'unix' repository.

Also, as unix .hsc files tend to be a bit fragile, portability wise, it
might be a good idea to instead place your patches in a separate library
on hackage, rather than patching the 'unix' package directly. We have
many other unix-alike packages, so one for message queues, and real time
scheduling make sense -- separate from the core 'unix' package (like the
mmap package, for example).

-- Don
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Don Stewart-2]

vigalchin:
>    so Don you are saying that mqueue and RTsched I should put on Hackage to
>    avoid putting in the Unix package? Vis-a-vis fsync and fdatasync I have no
>    choice .. they both IMO belong in Files.hsc.

Right, there are two options:

    1) put it in a new package. unix-extensions
or
    2) submit it as a patch to the libraries@... mailing list,
    and it can be put in the main 'unix' darcs repository, which then
    gets uploaded to hackage in the next release cycle.

It's currently a bug that anyone can (accidentally) release their own
versions of the core libraries.

Cheers,
  Don
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Ian Lynagh]

On Fri, May 09, 2008 at 11:21:40PM -0700, Donald Bruce Stewart wrote:
> vigalchin:
> >    so Don you are saying that mqueue and RTsched I should put on Hackage to
> >    avoid putting in the Unix package? Vis-a-vis fsync and fdatasync I have no
> >    choice .. they both IMO belong in Files.hsc.
>
>     2) submit it as a patch to the libraries@... mailing list,
>     and it can be put in the main 'unix' darcs repository, which then
>     gets uploaded to hackage in the next release cycle.

Or better still, follow
    http://www.haskell.org/haskellwiki/Library_submissions
so it doesn't end up being overlooked and forgotten about.

> It's currently a bug that anyone can (accidentally) release their own
> versions of the core libraries.

Yes, this mix-up is really our fault; we don't advertise or enforce our
policies well enough (I'm not even sure if we've got total agreement on
what they are?).

It's also raised an interesting question of who can upload the packages
maintained by libraries@. I guess we just create a sensible looking list
of people (roughly equal to those who release Haskell implementations
probably makes sense).


Thanks
Ian

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Bulat Ziganshin-2]

Hello Ian,

Saturday, May 10, 2008, 2:17:49 PM, you wrote:

> It's also raised an interesting question of who can upload the packages
> maintained by libraries@. I guess we just create a sensible looking list
> of people (roughly equal to those who release Haskell implementations
> probably makes sense).

i propose to assign password to each package uploaded to hackage and
require this password when next version of package is uploaded. it
should be easy to implement and should provide enough security for
our rather small community

--
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@...

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Ross Paterson]

On Sat, May 10, 2008 at 11:17:49AM +0100, Ian Lynagh wrote:

> On Fri, May 09, 2008 at 11:21:40PM -0700, Donald Bruce Stewart wrote:
> > It's currently a bug that anyone can (accidentally) release their own
> > versions of the core libraries.
>
> Yes, this mix-up is really our fault; we don't advertise or enforce our
> policies well enough (I'm not even sure if we've got total agreement on
> what they are?).
>
> It's also raised an interesting question of who can upload the packages
> maintained by libraries@. I guess we just create a sensible looking list
> of people (roughly equal to those who release Haskell implementations
> probably makes sense).

Up to now, releases of these packages have been part of GHC releases;
the versions on hackage have been images of the packages from GHC
source releases.  If we're going to do releases of them more often,
that ought to be done via the libraries list.

It's a special case of a broader problem with non-maintainer uploads
(i.e. releases), which cause exactly the same problems for other packages
too.  If we had an agreed policy we could advertise and enforce it, but
we don't.  I don't think that mechanized enforcement is the priority;
having a policy is.

We also need to ensure that the version in the darcs repo is larger
than the most recent release, but smaller than the release to follow.
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Bulat Ziganshin-2]

Hello Ross,

Saturday, May 10, 2008, 2:51:19 PM, you wrote:

> It's a special case of a broader problem with non-maintainer uploads
> (i.e. releases), which cause exactly the same problems for other packages
> too.  If we had an agreed policy we could advertise and enforce it, but
> we don't.  I don't think that mechanized enforcement is the priority;
> having a policy is.

at least we should start with it :)

i propose that uploader of first version takes "ownership" of package
which may be transferred to other person. uploads of subsequent
versions can be made by "owner" or his "trusted persons"

password-protection mechanism i've proposed in previous message
partially enforces this policy, although with many caveats. i hope,
though, that it will be enough for current community size

--
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@...

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Neil Mitchell]

Hi

> password-protection mechanism i've proposed in previous message
> partially enforces this policy, although with many caveats. i hope,

Yay, another password...

My suggestion would be that each account has a list of permissible
packages it can upload. i.e. Ian/Ross/Simon would all have their
accounts include unix as a permissible package. If a user uploads a
new package, which has not been on hackage before, it gets added to
their list. A little UI to allow logged in users to add additional
package maintainers and we'd be all sort - but the UI could come
later. In general it would enforce what we want, with no overhead in
the common case.

Thanks

Neil
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Duncan Coutts]

On Sat, 2008-05-10 at 12:31 +0100, Neil Mitchell wrote:

> Hi
>
> > password-protection mechanism i've proposed in previous message
> > partially enforces this policy, although with many caveats. i hope,
>
> Yay, another password...
>
> My suggestion would be that each account has a list of permissible
> packages it can upload. i.e. Ian/Ross/Simon would all have their
> accounts include unix as a permissible package. If a user uploads a
> new package, which has not been on hackage before, it gets added to
> their list. A little UI to allow logged in users to add additional
> package maintainers and we'd be all sort - but the UI could come
> later. In general it would enforce what we want, with no overhead in
> the common case.

Yes, I agree.

(I know it's a relation but it seems more intuitive to view it from the
package side rather than the user side)

Duncan

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Duncan Coutts]

On Sat, 2008-05-10 at 11:51 +0100, Ross Paterson wrote:

> It's a special case of a broader problem with non-maintainer uploads
> (i.e. releases), which cause exactly the same problems for other packages
> too.  If we had an agreed policy we could advertise and enforce it, but
> we don't.  I don't think that mechanized enforcement is the priority;
> having a policy is.

This seems like a good moment to revisit that discussion

http://haskell.org/pipermail/libraries/2008-February/009343.html

Here's a straw man policy:

We want packages to be uploaded by maintainers or someone the
maintainer/author has delegated that responsibility to.

Packages can be forked at any time but with new names. Transferring
maintenance of a package from one person to another is easy since it's
just delegation.

The tricky case is when the original maintainer/author disappears
without delegating/nominating new maintainers and a new volunteer wants
to pick up the package under the original name. We can borrow a policy
here from some existing organisation, the procedure usually involves
trying to find the maintainer, giving them time to respond, then
announcing that you want to take over maintenance and seeking feedback
and hopefully reaching a consensus.

Duncan

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Bulat Ziganshin-2]

Hello Duncan,

Saturday, May 10, 2008, 4:00:28 PM, you wrote:

> We want packages to be uploaded by maintainers or someone the
> maintainer/author has delegated that responsibility to.

> Packages can be forked at any time but with new names. Transferring
> maintenance of a package from one person to another is easy since it's
> just delegation.

there is a difference: generally speaking, we have a list of persons
that can upload new versions of package and list of persons who can
change the first list

am i correctly understood that you propose to make these lists
identical?


--
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@...

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Duncan Coutts]

On Sat, 2008-05-10 at 16:57 +0400, Bulat Ziganshin wrote:

> Saturday, May 10, 2008, 4:00:28 PM, you wrote:
>
> > We want packages to be uploaded by maintainers or someone the
> > maintainer/author has delegated that responsibility to.
>
> > Packages can be forked at any time but with new names. Transferring
> > maintenance of a package from one person to another is easy since it's
> > just delegation.
>
> there is a difference: generally speaking, we have a list of persons
> that can upload new versions of package and list of persons who can
> change the first list
>
> am i correctly understood that you propose to make these lists
> identical?

Yes, it's simpler.

Duncan

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[Neil Mitchell]

Hi

>> there is a difference: generally speaking, we have a list of persons
>> that can upload new versions of package and list of persons who can
>> change the first list
>>
>> am i correctly understood that you propose to make these lists
>> identical?
>
> Yes, it's simpler.

For the most part, yes. In reality, I suspect Ian/Ross/Simon and the
other Hackage admins will be able to edit all the lists.

Thanks

Neil
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries