Re: [Cython] New function (pointer) syntax.

[Dima Pasechnik]

On 2014-11-06, Robert Bradshaw  wrote:
> I'd like to propose a more pythonic way to declare function pointer
> types, namelye
>
> type0 (*[ident])(type1, type2, type3)
>
> would instead become
>
> (type1, type2, type3) -> type0 [ident]
>
> I have a pull request up at https://github.com/cython/cython/pull/333;
> what do people think?

we had a discussion with Volker about this few weeks ago - in my Cython code I
needed to do, as he suggested, a workaround like this:
 
   int* vlamatrix  "(int (*)[])" (int*) # a hack to get int (*)[] through cython

This was for 2-dim arrays of variable length, and looks similar to the 
stuff here.

IMHO it would be good to address this, too.
I'd rather stick to C99 conventions in Cython.
To me, using '->' for types looks way too close to what is used, with  
different semantics,  in functional languages like Haskell or Coq.


Dima

___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] New function (pointer) syntax.

[Dima Pasechnik]

On 10 November 2014 20:23, Robert Bradshaw  wrote:
> On Mon, Nov 10, 2014 at 6:25 AM, Dima Pasechnik  wrote:
>> On 2014-11-06, Robert Bradshaw  wrote:
>>> I'd like to propose a more pythonic way to declare function pointer
>>> types, namelye
>>>
>>> type0 (*[ident])(type1, type2, type3)
>>>
>>> would instead become
>>>
>>> (type1, type2, type3) -> type0 [ident]
>>>
>>> I have a pull request up at https://github.com/cython/cython/pull/333;
>>> what do people think?
>>
>> we had a discussion with Volker about this few weeks ago - in my Cython code 
>> I
>> needed to do, as he suggested, a workaround like this:
>>
>>int* vlamatrix  "(int (*)[])" (int*) # a hack to get int (*)[] through 
>> cython
>>
>> This was for 2-dim arrays of variable length, and looks similar to the
>> stuff here.
>>
>> IMHO it would be good to address this, too.
>
> Yeah.
>
>> I'd rather stick to C99 conventions in Cython.
>> To me, using '->' for types looks way too close to what is used, with
>> different semantics,  in functional languages like Haskell or Coq.
>
> Actually, the proposed use of '->' *is* identical to Haskell in
> semantics, i.e. "int -> int" is how you write a function taking and
> returning an int. Of course in Python one has a single argument tuple
> as input rather than currying.

well, I don't really see why ident is put at the end of the statement.
As you know, Haskell-like it would be

ident :: (type1, type2, type3) -> type0

if you work in postscript, then indeed putting ident at the end
would be natural :-)

Dima
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] Cygwin: Handling missing C99 long double functions

[Dima Pasechnik]

Hi,
certainly we did something with Sage on cygwin to work around these...
Just in case,
Dima

On Tue, Apr 26, 2016 at 3:58 PM, Erik Bray  wrote:
> Hi again,
>
> Sorry if I'm spamming the list too much, but I've encountered another
> pretty serious and unfortunate issue with Cython on Cygwin.
>
> The problem now is that many of libm long double functions like sqrtl,
> tanl, etc. are missing on Cygwin (missing from newlib to be specific).
> I think this is a previously known issue, but nothing's ever really
> been done about it.  Well, to be clear, sometimes they're present, but
> only when sizeof(double) == sizeof(long double).  However on 64-bit
> Cygwin sizeof(long double) == 16, so the functions are simply not
> defined.
>
> This seems to be due to lack of interest / effort:
> https://www.cygwin.com/ml/cygwin/2011-04/msg00231.html  That post is 5
> years old, but I can't find any evidence that this has changed.
>
> There are quite a few tests in Cygwin's test suite that test long
> double support.  I guess what I'm asking is what would be the best
> thing to do about it.
>
> I could just skip those tests on Cygwin, though I'm not sure the best
> way to go about skipping an entire test for a given platform.
>
> More generally though, outside the context of testing, this means
> Cygwin will sometimes generate code that cannot be compiled on this
> platform, and a question arises as to what to do about that.  I have
> some thoughts, but am not sure if it's worth discussing any further or
> not.
>
> Thanks,
> Erik
> ___
> cython-devel mailing list
> cython-devel@python.org
> https://mail.python.org/mailman/listinfo/cython-devel
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] Cython infrastructure

[Dima Pasechnik]

On Wed, Jul 20, 2016 at 10:55 AM, Baptiste Carvello
 wrote:
> Le 20/07/2016 08:01, Robert Bradshaw a écrit :
>
>> trac.cython.org
>> This is probably the most controversial, but I think it makes sense to
>> migrate to github issues. While clearly not as powerful, featureful,
>> or customizable as trac, it seems it would fulfill our modest needs. I
>> am happy to do the migration if no one objects.
>
> I suppose the dev guide will be updated with advice on how users without
> a Github ID should report and interact with issues. It may lead to more
> issues-related discussion on this mailing list.
>
> Cheers,
> Baptiste
>
> For avoidance of doubt: "subscribe to Github" is not an acceptable
> answer, given that this means consenting to be tracked, not only inside
> the Cython project, but also across projects.

Github is not spyware, IMHO. It would be good to understand which of these:

https://help.github.com/articles/github-privacy-policy/

you have a problem with.

Yes, you will need to allow cookies in your browser.
Anything else seems to be irrelevant.

Best,
Dima
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] Cython infrastructure

[Dima Pasechnik]

On Thu, Jul 21, 2016 at 9:42 AM, Baptiste Carvello
 wrote:
> Le 20/07/2016 12:19, Dima Pasechnik a écrit :
>
>> Github is not spyware, IMHO. It would be good to understand which of these:
>>
>> https://help.github.com/articles/github-privacy-policy/
>>
>> you have a problem with.
>
> That's this one, in the terms of service:
>
> "One person or legal entity may not maintain more than one free account,
> and one machine user account that is used exclusively for performing
> automated tasks."
>
> Which means the account identifies me as a person, not just as a project
> member, and they can correlate my actions across all projects.
>
Apart from browser cookies, they have no real means to identify users
having several identities.
This is merely done for preventing abuse by people who basically use
so much resource that they ought to pay.

That is, yes, you will need one email address per one account, and would not
try to have a 100 of such identities accessing github from the same IP.

At worst you will lose an account, that's all.

Dima

> Baptiste
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] Cython infrastructure

[Dima Pasechnik]

On Thu, Jul 21, 2016 at 10:18 AM, Baptiste Carvello
 wrote:
> Le 20/07/2016 19:23, Robert Bradshaw a écrit :
>
>> +1
>>
>> I'm a big advocate of privacy, and informed consent when choosing to
>> give any of it away (e.g. allowing linking of activities to build a
>> (pseudonymous or not) reputation).
>
> (philosophical side note: "consent" is not free of coercion, and thus
> rather irrelevant, when Github is taking over 90% of Open Source projects.)
>
>> [...] Personally, I'm actually quite
>> happy to have my activities on github correlated with my identity.
>> (Actually, it's a net plus, not a concession.)
>
> I understand your point, but I'd like to make a different choice.
>
>> Of course you can always set up any number of unrelated pseudonyms on
>> github, delete cookies, use incognito mode, and even do everything via
>> tor if you really want.
>
> No, I can't (unless I want to play cat and mouse with them, which is no
> fun). And that is the whole of the problem, as I say in my other message.

Actually, it's not clear why this is a problem. If you do not want to
play cat and
mouse (which means removing cookies often, etc), you would create an
identity that
only you know, and let this avatar do all the talking and working on github.
There are plenty of github users out there like this, nobody sees who
they really are.
(github knows a working email address for them, that's basically all).

>
>> However, while "Subscribe to Github" is a perfectly reasonable answer,
>> and one that would in practice include more people than it would
>> exclude (compared to our current system, or many alternatives), it's
>> not like we're going to suddenly refuse all discussions of bugs on the
>> mailing lists. We're low enough volume to be flexible. A real bug
>> tracker is simply more useful for tracking issues than an inbox.
>
> As long as the mailing list stays, any concrete difficulty can be solved
> when it arises through a constructive discussion, so nothing is lost!
>
> I trust that Cython won't ever do like some other projects, which have
> suppressed any kind of non-Github contact channel. That would be the
> real pain.

IMHO this is just spreading FUD.
Many, many projects with presence on github have, say, google groups
or/and non-github based bug/issue trackers as primary means of
communication. Noone ever heard of github undermining these projects
in any way.

Dima

>
>> Does this alleviate your concerns?
>
> Not fully, but I can live with it :-)
>
> Baptiste
>
> ___
> cython-devel mailing list
> cython-devel@python.org
> https://mail.python.org/mailman/listinfo/cython-devel
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] Cython 0.29 – or 29.0 ?

[Dima Pasechnik]

I'd vote for sanity over marketing, i.e. 1.0.


On Fri, Aug 17, 2018 at 11:53 AM James C. McPherson
 wrote:
>
>
> 1.0 runs the risk of hitting "never install a 1.0 release" habits.
>
> Jumping to 29.0 would not, imnsho, be such an issue because people
> are used to the rapid cadence of Firefox, Thunderbird and Chrome
> releases. The flip side of 29.0 would be the question "when are you
> announcing your LTS version?"
>
> James
>
>
> On 08/16/18 08:48 AM, Robert Bradshaw wrote:
> > If we're going to ditch the 0.x, I'd go for 1.0 as well. I'm a huge fan of
> > semantic versioning.
> >
> > The primary reasons we kept the 0.x scheme were that
> >
> > * We wanted full compatibility with CPython (we're nearly there, or at
> > least it's safe to say the differences are on par with those between
> > different versions and implementations of Python), and
> > * We wanted the flexibility to possibly jettison archaic features of the
> > language or otherwise clean things up.
> >
> > It's worth revisiting to see if either of these are still relevant (*and*
> > likely to be worked on in the near future).
> >
> >
> >
> > On Wed, Aug 15, 2018 at 10:40 PM, Jeroen Demeyer  > > wrote:
> >
> > I vote for 1.0
> >
> > Version 29.0 sounds too much like marketing.
> >
> > ___
> > cython-devel mailing list
> > cython-devel@python.org 
> > https://mail.python.org/mailman/listinfo/cython-devel
> > 
> >
> >
> >
> >
> > ___
> > cython-devel mailing list
> > cython-devel@python.org
> > https://mail.python.org/mailman/listinfo/cython-devel
> >
>
>
> --
> Oracle
> Systems / Solaris / Core
> Solaris WOS Tech Lead
> https://www.jmcpdotcom.com/blog
> ___
> cython-devel mailing list
> cython-devel@python.org
> https://mail.python.org/mailman/listinfo/cython-devel
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] cython 3 migration update and next releases

[Dima Pasechnik]

SageMath has 700K Cython lines, yet not mentioned.

On Sun, 21 May 2023, 10:21 Stefane Fermigier,  wrote:

>
> On 17/05/2023 14:44, Lisandro Dalcin wrote:
>
>
>
> On Tue, 16 May 2023 at 22:10, matus valo  wrote:
>
>>  The rationale is that the projects won't start really using Cython 3
>> until we do the final release. Now, we have 3 big users of Cython migrated,
>> hence I think we have some confidence that Cython 3 is ready. What do you
>> think?
>>
>
> I would not say that mpi4py is a big project, but it is around 15K lines
> of Cython code, and it is also ready for Cython 3. I'll update mpi4py
> requirements to `cython>=3` as soon as Cython 3 is released.
>
>
> IFAIK, 15k lines of Cython makes it among one of the largest Cython
> projects I'm aware of (I did some research a couple of years ago):
>
>
> https://github.com/sfermigier/awesome-cython#some-projects-with-more-that-10-000-lines-of-cython-code
>
>   S.
>
> --
>
> Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier
> - http://linkedin.com/in/sfermigier
>
> Founder & CEO, Abilian - Enterprise Social Software -
> http://www.abilian.com/
>
> Founder & Software Architect - Nua open source PaaS project -
> https://nua.rocks/
>
> Co-Founder & Co-Chairman, National Council for Free & Open Source Software
> (CNLL) - http://cnll.fr/
>
> Co-Founder & Board Member, Association Professionnelle Européenne du
> Logiciel Libre (APELL) - https://www.apell.info/
>
> Co-Founder & Spokesperson, European Cloud Industrial Alliance (EUCLIDIA) -
> https://www.euclidia.eu/
> ___
> cython-devel mailing list
> cython-devel@python.org
> https://mail.python.org/mailman/listinfo/cython-devel
>
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel

Re: [Cython] cython 3 migration update and next releases

[Dima Pasechnik]

On thing to take care of before the release is to get rid of the hugely outdated
advice to ship generated C/C++ files!

On Sun, May 21, 2023 at 11:24 AM Stefan Behnel  wrote:
>
> Dima Pasechnik schrieb am 21.05.23 um 11:38:
> > On Sun, 21 May 2023, 10:21 Stefane Fermigier,  wrote:
> >> IFAIK, 15k lines of Cython makes it among one of the largest Cython
> >> projects I'm aware of (I did some research a couple of years ago):
> >>
> >> https://github.com/sfermigier/awesome-cython#some-projects-with-more-that-10-000-lines-of-cython-code
> >
>  > SageMath has 700K Cython lines, yet not mentioned.
>
> Certainly worth mentioning, yes.
>
> Looking at the numbers, I also noticed that lxml is listed in the 5-10k
> lines range. It actually has about 18k lines of Cython code (.pyx/.pxi
> files) and another 1.5k lines in compiled Python (.py) files, according to
> pygount [1]. I tried sloccount first, but that doesn't seem to have Cython
> support.
>
> Might be worth redoing that count for the other projects as well.
>
> Stefan
>
>
> [1] https://pypi.org/project/pygount/
>
> ___
> cython-devel mailing list
> cython-devel@python.org
> https://mail.python.org/mailman/listinfo/cython-devel
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel