Opened 7 years ago

Closed 3 years ago

#13841 closed enhancement (worksforme)

Cygwin metaticket: port Sage to Microsoft Windows (via Cygwin)

Reported by: kcrisman Owned by: tbd
Priority: major Milestone: sage-duplicate/invalid/wontfix
Component: porting: Cygwin Keywords:
Cc: jpflori, dimpase, was, eviatarbach Merged in:
Authors: Reviewers: Jean-Pierre Flori, Karl-Dieter Crisman
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: #6743 Stopgaps:

Description (last modified by jdemeyer)

Thanks to #6743, Sage now builds on Cygwin with make and appropriate prereqs.

This metaticket tracks further status of Sage on Cygwin.

Change History (19)

comment:1 Changed 7 years ago by kcrisman

  • Dependencies set to #6743
  • Description modified (diff)
  • Milestone changed from sage-5.8 to sage-pending
  • Status changed from new to needs_review

Looks like we won't need this... of course, one never knows, with all the upgrades to spkgs in every version! Anyway, I'm setting this to sage-pending on #6743 for now.

comment:2 Changed 7 years ago by jpflori

I guess we should close this one.

comment:3 Changed 7 years ago by kcrisman

Until #6743 is merged, I say never say never! There always seems to be some crazy thing that stands in the way.

comment:4 follow-up: Changed 7 years ago by kcrisman

  • Reviewers set to Jean-Pierre Flori, Karl-Dieter Crisman

Given that #6743 is closed (though not merged in a specific Sage version yet), perhaps this should be as well now? Are the 5.10 betas doing well on Cygwin?

With respect to keeping it working... JP, are you saying that you have the hardware and time to commit to monitoring this for (say) 2 years? I just don't have the access to Windows/time to mess with them often enough to guarantee this; given how finicky Cygwin is, we will likely have to keep fixing things that other tickets do - either in terms of missing includes in pyx files or in terms of spkgs which don't have proper stuff... Thanks for all your amazing work on this!

comment:5 in reply to: ↑ 4 ; follow-up: Changed 7 years ago by jdemeyer

Replying to kcrisman:

JP, are you saying that you have the hardware and time to commit to monitoring this for (say) 2 years?

I think hardware shouldn't be the problem, I'm sure William can setup a VM for this if needed. Time, on the other hand, is a more valuable resource...

comment:6 in reply to: ↑ 5 Changed 7 years ago by jpflori

Replying to jdemeyer:

Replying to kcrisman:

JP, are you saying that you have the hardware and time to commit to monitoring this for (say) 2 years?

I think hardware shouldn't be the problem, I'm sure William can setup a VM for this if needed.

Yeah that would be very helpful, at least for a buildbot (though it may need human intervention somehow because of rebasing issues, but also note that 64 bits cygwin is on its way and seems quite already in a usale state except for the lack of an installer and me being able to find where to downnload it!).

Time, on the other hand, is a more valuable resource...

For at least one year, or mybe two years, i.e. until I change job, I should have some time for that.

comment:7 follow-up: Changed 7 years ago by jpflori

And having VMs already turned on somewhere would also be nice to run things such as "make ptestlong" which are incredibly slow because of forking.

comment:8 Changed 7 years ago by dimpase

A buildbot would need a cygwin-less way to log in onto it, otherwise rebasing can't always be done. And the standard WIndows way (with a GUI -- "remote desktop connection") might be too slow if the work needs to be done across continents. Are there alternatives? I don't really know. There are sshd "native" WIndows implementations, but I never tried them.

comment:9 follow-up: Changed 7 years ago by jpflori

Using "rebase -O" should be possible even though other Cygwin processes are running (as long as nothing from Sage is).

comment:10 in reply to: ↑ 9 Changed 7 years ago by dimpase

Replying to jpflori:

Using "rebase -O" should be possible even though other Cygwin processes are running (as long as nothing from Sage is).

yes, but if you want to install a new version of Sage, then you probably want to wipe the rebase databases and do a full, cygwin-less, rebase.

comment:11 follow-up: Changed 7 years ago by jpflori

I'd say the trick would be to never let Sage enter the rebase database by only using "rebase -O" :)

comment:12 in reply to: ↑ 11 ; follow-up: Changed 7 years ago by dimpase

Replying to jpflori:

I'd say the trick would be to never let Sage enter the rebase database by only using "rebase -O" :)

Are you sure that "rebase -O" does not add stuff to the database? I thought it does, it just does not move what's already there...

comment:13 in reply to: ↑ 12 ; follow-up: Changed 7 years ago by jpflori

Replying to dimpase:

Replying to jpflori:

I'd say the trick would be to never let Sage enter the rebase database by only using "rebase -O" :)

Are you sure that "rebase -O" does not add stuff to the database? I thought it does, it just does not move what's already there...

Yup, completely sure, it just reads what's there to rebase after what already exists, but does not write anything.

E.g. if you "rebase -O" two copies of sage and try to run them at the same time, it will likely fail because "rebase -O" will have used the same addesses.

comment:14 in reply to: ↑ 7 Changed 7 years ago by jdemeyer

Replying to jpflori:

And having VMs already turned on somewhere would also be nice to run things such as "make ptestlong" which are incredibly slow because of forking.

What is "incredibly slow"? For me, there is no problem if Sage can be built and tested within 48 hours. Is that feasible?

comment:15 in reply to: ↑ 13 Changed 7 years ago by dimpase

Replying to jpflori:

Replying to dimpase:

Replying to jpflori:

I'd say the trick would be to never let Sage enter the rebase database by only using "rebase -O" :)

Are you sure that "rebase -O" does not add stuff to the database? I thought it does, it just does not move what's already there...

Yup, completely sure, it just reads what's there to rebase after what already exists, but does not write anything.

The mapping of dlls to addresses must be stored somewhere. (where?) Are you saying that the next run of "rebase -O" completely erases this mapping, and builds a new one from scratch?

comment:16 Changed 7 years ago by jpflori

I'd say it's stored into the dlls themselves, not sure though, but not in the system-wide database for sure, my usual user doesnt have write access to it anyway.

I'm not sure a second run would change everything, it just acts like a usual rebase (without -O) but does not record the results into the system-wide database, so if no dll was added into the global database and you're not adding new stuff to the list of additional files you want to rebase then nothing will change (maybe if you remove some then it will try to pack the address space used).

comment:17 Changed 7 years ago by eviatarbach

  • Cc eviatarbach added

comment:18 Changed 6 years ago by jdemeyer

  • Description modified (diff)
  • Status changed from needs_review to needs_info
  • Summary changed from cygwin metaticket: port Sage to Microsoft Windows (via Cygwin): stage 2 -- Sage starts and passes a lot of doctests to Cygwin metaticket: port Sage to Microsoft Windows (via Cygwin)

comment:19 Changed 3 years ago by embray

  • Milestone changed from sage-pending to sage-duplicate/invalid/wontfix
  • Resolution set to worksforme
  • Status changed from needs_info to closed

This ticket hasn't been updated in 4+ years, and doesn't really discuss anything that's still an open issue for the Cygwin port.

The best way right now to track progress on the Cygwin port is to just search on the porting: Cygwin component.

Note: See TracTickets for help on using tickets.