Tony, If the evaluator fails under Windows, the package could automatically flagged as Linux/Mac only. I have no problem with trying to port some of these to Windows, but having no access to any other OS, some hints from the authors would be very useful: What shared libraries are used, and where are they? What OS features are used (e.g. shell commands)? Waht file/data formats are assumed? Etc. An automatic flagging could not provide this. Basic documentation guidelines to package authors and their cooperation would highly be appreciated.
Laszlo On Saturday, April 19, 2014 10:58:16 AM UTC-6, Tony Kelman wrote: > > Laszlo, > > Getting CUDA working on Windows would be great. Experimenting with GPU's > (on Windows or elsewhere) has been on my to-do list for a while. > > Unfortunately with the current state of Julia's package ecosystem, it's > safer to assume any packages with non-Julia dependencies don't work on > Windows unless you can see evidence of BinDeps work and documentation > specific to Windows. A note in Package documentation that says "not tested > under Windows" would certainly help here, but has not yet been a formal > requirement. Maybe it should be, for packages with non-Julia dependencies. > > This situation will improve with time, but only if users experiment with > things and help identify ways of fixing problems. Open issues and PR's > anywhere you run into trouble with a package on Windows. I posted to the > mailing lists last month about work I had done to enable Windows CI using > AppVeyor, but as of yet it appears very few packages have done so. I also > haven't gone hunting for packages to try doing it myself and submitting > PR's to, which would likely end up being more effective than hoping package > maintainers do it of their own accord. > > I just opened an issue at > https://github.com/IainNZ/PackageEvaluator.jl/issues/51 to discuss > getting Windows package testing into PackageEvaluator, if that might be > possible. > > -Tony > > > On Saturday, April 19, 2014 9:33:59 AM UTC-7, Laszlo Hars wrote: >> >> Tobias, >> >> It is not a bug: the CUDA package was developed for Linux-like systems, >> only. The Julia documentation links to a list of registered packages, so it >> was natural to assume that those packages had been endorsed by the language >> developers, and work in Julia installations under Windows. Only if you dig >> into the text deeper you learn that any code can get registered and listed >> there. My misunderstanding was that I assumed that these packages have been >> approved, and they should work under Windows. Maybe an explicit note in the >> Julia documentation, saying that registered packages are not tested or >> approved by the Julia developers would help avoiding this confusion. >> >> I think it is OK to register a package which only works under a certain >> OS: just add a note, as I requested, either in the title (e.g. "CUDA for >> Linux") or in the README. Dahua did this since. >> >> In the mean time, as you could have seen, I did fix the issue. I don't >> agree that I should simply edit the README.jl. I have to first understand >> what is wrong and what causes the problem. This is why I have asked the >> question here. This is a wonderful community: I usually get answers to my >> questions within minutes. This time there was no relevant response until I >> sent an email directly to Dahua, who confirmed the problem, but could not >> offer a fix. Only then I went ahead to find and fix the issue. I will have >> to test the fix and follow through all the way to see if it works as >> expected, and then I will post a note to GIT. >> >> Laszlo >> >> >> On Friday, April 18, 2014 11:20:52 PM UTC-6, Tobias Knopp wrote: >>> >>> I don't see your problem. You have found a bug in an open source >>> project, i.e. that the package does not work on windows. >>> There are two options to solve this: >>> - Fix the windows issue >>> - Fix the documentation on https://github.com/lindahua/CUDA.jl >>> As you are not the maintainer of this project the best thing to solve >>> this is to report the issue on the CUDA.jl bug tracker and/or provide a PR >>> to fix the issue or fix the documentation. You can just click on README.jl >>> on https://github.com/lindahua/CUDA.jl and change the file which will >>> notify Dahua who would than merge your proposed documentation change. >>> >>> This is how open source works. Proposing to remove the package from the >>> Pkg manager on the Julia mailing list without reporting an issue on the >>> project page where it belongs to is certainly not the right way to do this. >>> And even when you get no reaction on the mailing list or a bug tracker you >>> should never get angry/frustrated about this. What is if Dahua is on >>> vacation surfing in Hawaii for two weeks. Do you expect him to answer to >>> your messages in that time? >>> >>> There is certainly a point about the quality of packages in the Julia >>> ecosystem. In my opinion the most important thing here is automatic testing >>> on all major platforms, which is if I recall right already available. Maybe >>> it would also be good to have some kind of popularity measure. In this way >>> one could list only the "popular" packages which are in use and not the >>> experimental ones. >>> >>> Am Samstag, 19. April 2014 02:51:47 UTC+2 schrieb Laszlo Hars: >>>> >>>> Tim: We spend too much time on this. I don't believe that telling in >>>> the package home page under what OS the package was tested, and what >>>> external functions are used is too much burden. It should be the norm, but >>>> obviously I am alone with this view. -Laszlo >>>> >>>
