Re: [Tinycc-devel] github
How about Darling? https://darlinghq.org/ Regards -- Federico Bianchi polo 4 @ SID UniPI.IT On Tue, 21 Apr 2020, Christian Jullien wrote: Are there macOS images? Because if so, I could probably look at adding Mach-O support on a rainy day. Without access to MacOS that's going to be difficult :) Wouah! I'd love to have it. -Original Message- From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Michael Matz Sent: Tuesday, April 21, 2020 16:05 To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] github Hello, On Sun, 19 Apr 2020, Giovanni Mascellani wrote: TinyCC is great because it supports so much configurations (3 OSes, even more CPU archs). But the downside is, that nobody can ensure that his change wont break any of these configurations. (Probably most of us are testing only on their own PC, which is one OS with probably x86-64). How about a CI? I am not a core dev, but I set up a CI for tcc: https://gitlab.com/giomasce/tinycc/pipelines Unfortunately it is currently broken. I believe the CI is broken, not tcc, because it wasn't broken before my last round of CI script maintenance. I'll try to fix them as soon as I have some time, but if someone wants to check them out in the meantime I won't complain. Yeah, I've seen the breakages, but had no bright idea, see below. Currently armhf fails with "Illegal instruction", and I don't know if the problem is QEMU emulation or tcc itself, because the same commit did work before I did my last round of changes. Yeah, I figured something must be up with the emulator. No way TCC is generating genuinely illegal instructions :) It would be helpful if the emulator would give some hint of the instruction bytes it thinks are illegal :) (One guess of mine was that the emulator is run in a mode where e.g. Neon instructions are invalid?) riscv64 has a failing test, and that could be a genuine tcc bug. If so, it is probably introduced by recent "win32: long double as distinct C-type" commit. Broken test is "70_floating_point_literals", see the log[1]. Yeah, but I don't think there's a TCC problem. The failure in riscv64 is random (i.e. changes place from test to test, when the pipelines are re-triggered by unrelated changes, just browse the different fails). I've looked at one of the testcases claimed to be failing and it's definitely correct code. [1] https://gitlab.com/giomasce/tinycc/-/jobs/507946108 As soon as I have some time, I'd like to fix these problems and eventually support Windows and macOS too. I believe this architecture with QEMU running in GitLab CI can work, but suitable Windows and macOS images have to be prepared and compilation scripts adapted. QEMU TCG emulation is slowish, but if we prepare images with a snapshot so that the VM doesn't have to go through the whole boot sequence it might be reasonable. Are there macOS images? Because if so, I could probably look at adding Mach-O support on a rainy day. Without access to MacOS that's going to be difficult :) Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] github
> Are there macOS images? Because if so, I could probably look at adding > Mach-O support on a rainy day. Without access to MacOS that's going to be > difficult :) Wouah! I'd love to have it. -Original Message- From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Michael Matz Sent: Tuesday, April 21, 2020 16:05 To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] github Hello, On Sun, 19 Apr 2020, Giovanni Mascellani wrote: >> TinyCC is great because it supports so much configurations (3 OSes, even >> more CPU archs). >> >> But the downside is, that nobody can ensure that his change wont break >> any of these configurations. >> (Probably most of us are testing only on their own PC, which is one OS >> with probably x86-64). >> >> How about a CI? > > I am not a core dev, but I set up a CI for tcc: > > https://gitlab.com/giomasce/tinycc/pipelines > > Unfortunately it is currently broken. I believe the CI is broken, not > tcc, because it wasn't broken before my last round of CI script > maintenance. I'll try to fix them as soon as I have some time, but if > someone wants to check them out in the meantime I won't complain. Yeah, I've seen the breakages, but had no bright idea, see below. > Currently armhf fails with "Illegal instruction", and I don't know if > the problem is QEMU emulation or tcc itself, because the same commit did > work before I did my last round of changes. Yeah, I figured something must be up with the emulator. No way TCC is generating genuinely illegal instructions :) It would be helpful if the emulator would give some hint of the instruction bytes it thinks are illegal :) (One guess of mine was that the emulator is run in a mode where e.g. Neon instructions are invalid?) > riscv64 has a failing test, and that could be a genuine tcc bug. If so, > it is probably introduced by recent "win32: long double as distinct > C-type" commit. Broken test is "70_floating_point_literals", see the > log[1]. Yeah, but I don't think there's a TCC problem. The failure in riscv64 is random (i.e. changes place from test to test, when the pipelines are re-triggered by unrelated changes, just browse the different fails). I've looked at one of the testcases claimed to be failing and it's definitely correct code. > [1] https://gitlab.com/giomasce/tinycc/-/jobs/507946108 > > As soon as I have some time, I'd like to fix these problems and > eventually support Windows and macOS too. I believe this architecture > with QEMU running in GitLab CI can work, but suitable Windows and macOS > images have to be prepared and compilation scripts adapted. QEMU TCG > emulation is slowish, but if we prepare images with a snapshot so that > the VM doesn't have to go through the whole boot sequence it might be > reasonable. Are there macOS images? Because if so, I could probably look at adding Mach-O support on a rainy day. Without access to MacOS that's going to be difficult :) Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] github
Hello Robert, On Sat, 18 Apr 2020, Robert Hölzl wrote: How about a CI? See also https://gitlab.com/giomasce/tinycc/pipelines . I would be happy to add the corresponding scripts, so that at least windows (x86 and x64), linux (x64) and macos (x64) are tested. I did not investigate yet, but it could be even possible to utlitze qemu to test all cpu archs (not only x86, x64). But to make this work I need the repo to be homed at github or gitlab. It seems that on github there is already an organization "TinyCC". Bit it seems not to be supported by the core devs. In fact the guy which created this repo even started some CI scripts. @the core devs: Please point our your thoughts. Are you interested in a CI (even it might need a switch to GitHub/GitLab/...) I think a CI is worthwhile to have, if people look at it at least semi regularly. But a mirror is enough to have a CI running. Ciao, Michael.___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] github
Hello, On Sun, 19 Apr 2020, Giovanni Mascellani wrote: TinyCC is great because it supports so much configurations (3 OSes, even more CPU archs). But the downside is, that nobody can ensure that his change wont break any of these configurations. (Probably most of us are testing only on their own PC, which is one OS with probably x86-64). How about a CI? I am not a core dev, but I set up a CI for tcc: https://gitlab.com/giomasce/tinycc/pipelines Unfortunately it is currently broken. I believe the CI is broken, not tcc, because it wasn't broken before my last round of CI script maintenance. I'll try to fix them as soon as I have some time, but if someone wants to check them out in the meantime I won't complain. Yeah, I've seen the breakages, but had no bright idea, see below. Currently armhf fails with "Illegal instruction", and I don't know if the problem is QEMU emulation or tcc itself, because the same commit did work before I did my last round of changes. Yeah, I figured something must be up with the emulator. No way TCC is generating genuinely illegal instructions :) It would be helpful if the emulator would give some hint of the instruction bytes it thinks are illegal :) (One guess of mine was that the emulator is run in a mode where e.g. Neon instructions are invalid?) riscv64 has a failing test, and that could be a genuine tcc bug. If so, it is probably introduced by recent "win32: long double as distinct C-type" commit. Broken test is "70_floating_point_literals", see the log[1]. Yeah, but I don't think there's a TCC problem. The failure in riscv64 is random (i.e. changes place from test to test, when the pipelines are re-triggered by unrelated changes, just browse the different fails). I've looked at one of the testcases claimed to be failing and it's definitely correct code. [1] https://gitlab.com/giomasce/tinycc/-/jobs/507946108 As soon as I have some time, I'd like to fix these problems and eventually support Windows and macOS too. I believe this architecture with QEMU running in GitLab CI can work, but suitable Windows and macOS images have to be prepared and compilation scripts adapted. QEMU TCG emulation is slowish, but if we prepare images with a snapshot so that the VM doesn't have to go through the whole boot sequence it might be reasonable. Are there macOS images? Because if so, I could probably look at adding Mach-O support on a rainy day. Without access to MacOS that's going to be difficult :) Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] github
Hi, I can just say that armhf is not broken on a real (RPi 4) plateform. -Original Message- From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Giovanni Mascellani Sent: Sunday, April 19, 2020 08:29 To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] github Hi, Il 18/04/20 21:05, Robert Hölzl ha scritto: > hey guys, > > TinyCC is great because it supports so much configurations (3 OSes, > even more CPU archs). > > But the downside is, that nobody can ensure that his change wont break > any of these configurations. > (Probably most of us are testing only on their own PC, which is one OS > with probably x86-64). > > How about a CI? I am not a core dev, but I set up a CI for tcc: https://gitlab.com/giomasce/tinycc/pipelines Unfortunately it is currently broken. I believe the CI is broken, not tcc, because it wasn't broken before my last round of CI script maintenance. I'll try to fix them as soon as I have some time, but if someone wants to check them out in the meantime I won't complain. The thing is currently set up with an automatic script on a server of mine that periodically checks for new commits and sends them to the repository on GitLab (branch "test"). Those scripts automatically compile and run tcc's tests in the native GitLab CI environment and on five different Debian systems of different architectures by mean of QEMU whole system emulation (i386, amd64, armhf, arm64 and riscv64). Currently armhf fails with "Illegal instruction", and I don't know if the problem is QEMU emulation or tcc itself, because the same commit did work before I did my last round of changes. riscv64 has a failing test, and that could be a genuine tcc bug. If so, it is probably introduced by recent "win32: long double as distinct C-type" commit. Broken test is "70_floating_point_literals", see the log[1]. [1] https://gitlab.com/giomasce/tinycc/-/jobs/507946108 As soon as I have some time, I'd like to fix these problems and eventually support Windows and macOS too. I believe this architecture with QEMU running in GitLab CI can work, but suitable Windows and macOS images have to be prepared and compilation scripts adapted. QEMU TCG emulation is slowish, but if we prepare images with a snapshot so that the VM doesn't have to go through the whole boot sequence it might be reasonable. HTH, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] github
Hi, Il 18/04/20 21:05, Robert Hölzl ha scritto: > hey guys, > > TinyCC is great because it supports so much configurations (3 OSes, even > more CPU archs). > > But the downside is, that nobody can ensure that his change wont break > any of these configurations. > (Probably most of us are testing only on their own PC, which is one OS > with probably x86-64). > > How about a CI? I am not a core dev, but I set up a CI for tcc: https://gitlab.com/giomasce/tinycc/pipelines Unfortunately it is currently broken. I believe the CI is broken, not tcc, because it wasn't broken before my last round of CI script maintenance. I'll try to fix them as soon as I have some time, but if someone wants to check them out in the meantime I won't complain. The thing is currently set up with an automatic script on a server of mine that periodically checks for new commits and sends them to the repository on GitLab (branch "test"). Those scripts automatically compile and run tcc's tests in the native GitLab CI environment and on five different Debian systems of different architectures by mean of QEMU whole system emulation (i386, amd64, armhf, arm64 and riscv64). Currently armhf fails with "Illegal instruction", and I don't know if the problem is QEMU emulation or tcc itself, because the same commit did work before I did my last round of changes. riscv64 has a failing test, and that could be a genuine tcc bug. If so, it is probably introduced by recent "win32: long double as distinct C-type" commit. Broken test is "70_floating_point_literals", see the log[1]. [1] https://gitlab.com/giomasce/tinycc/-/jobs/507946108 As soon as I have some time, I'd like to fix these problems and eventually support Windows and macOS too. I believe this architecture with QEMU running in GitLab CI can work, but suitable Windows and macOS images have to be prepared and compilation scripts adapted. QEMU TCG emulation is slowish, but if we prepare images with a snapshot so that the VM doesn't have to go through the whole boot sequence it might be reasonable. HTH, Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles signature.asc Description: OpenPGP digital signature ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] github
Hi, For sure I would like to have a CI. I personally test about every commit on Windows x86/x64, Linux arm32/arm64 and a little bit less often on Linux x64/Alpine x64. I definitively would like to test Linux/rsicv64 too but I lack access to a machine having this cpu. GitHub has another advantage, it perhaps more stable than current repository. Why don't you setup a pure mirror on GitHub just for CI and without the possibility to commit on it? This mirror will synchronize, say, every 4 hours and launch non-regression tests for all supported os/system. C. -Original Message- From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Robert Hölzl Sent: Saturday, April 18, 2020 21:05 To: tinycc-devel@nongnu.org Subject: [Tinycc-devel] github hey guys, TinyCC is great because it supports so much configurations (3 OSes, even more CPU archs). But the downside is, that nobody can ensure that his change wont break any of these configurations. (Probably most of us are testing only on their own PC, which is one OS with probably x86-64). How about a CI? I would be happy to add the corresponding scripts, so that at least windows (x86 and x64), linux (x64) and macos (x64) are tested. I did not investigate yet, but it could be even possible to utlitze qemu to test all cpu archs (not only x86, x64). But to make this work I need the repo to be homed at github or gitlab. It seems that on github there is already an organization "TinyCC". Bit it seems not to be supported by the core devs. In fact the guy which created this repo even started some CI scripts. @the core devs: Please point our your thoughts. Are you interested in a CI (even it might need a switch to GitHub/GitLab/...) greets, Robert ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] github
hey guys, TinyCC is great because it supports so much configurations (3 OSes, even more CPU archs). But the downside is, that nobody can ensure that his change wont break any of these configurations. (Probably most of us are testing only on their own PC, which is one OS with probably x86-64). How about a CI? I would be happy to add the corresponding scripts, so that at least windows (x86 and x64), linux (x64) and macos (x64) are tested. I did not investigate yet, but it could be even possible to utlitze qemu to test all cpu archs (not only x86, x64). But to make this work I need the repo to be homed at github or gitlab. It seems that on github there is already an organization "TinyCC". Bit it seems not to be supported by the core devs. In fact the guy which created this repo even started some CI scripts. @the core devs: Please point our your thoughts. Are you interested in a CI (even it might need a switch to GitHub/GitLab/...) greets, Robert ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Github
Apart from that: does github have kind of like mob branches by default? Because, quite frankly, that's the only reason I contributed anything, however small, back to tinycc. If it hadn't I still would have had fun for a weekend fixing tcc, justwithout anybody gaining anything from it, as my patches would have never seen anybody else, and nobody would have seen them. Github makes it easy to collaborate with public visible pull requests. http://help.github.com/send-pull-requests/ Higher google rank, Huh? So you think google is giving points for github, but not for repo.or.cz (the best), or gitorious or any of the others? Proof? Github makes it easy for Google to index the important information. Good SEO overall :D nice readme, Doesn't write itself, no matter the VCS. So how does a new VCS magically help? Github makes the README prominent readable on the front-page of the repository. Much less visible with repo.or.cz easier forks Well, I'm not exactly fluent in git (actually I hate its usability, which is next to non-existent), but what's difficult with git checkout -b? Public visible fork networks: https://github.com/libarchive/libarchive/network etc. You could use Travis.CI (http://travis-ci.org/) as continuous integration service. Organization Examples: https://github.com/luvit/luvit https://github.com/libarchive/libarchive Kind regards, Karl Skomski On Tue, May 15, 2012 at 1:28 AM, Michael Matz matz@frakked.de wrote: Hi, On Mon, 14 May 2012, Karl Skomski wrote: Hi, I discovered tinycc some days ago but only today I discovered the current development repository: http://repo.or.cz/w/tinycc.git It's not that easy to find the most-updated tinycc repository. I thought maybe it would be nice to switch the tinycc repository to a github organization? How exactly would that help spreading interest (except in github)? Apart from that: does github have kind of like mob branches by default? Because, quite frankly, that's the only reason I contributed anything, however small, back to tinycc. If it hadn't I still would have had fun for a weekend fixing tcc, just without anybody gaining anything from it, as my patches would have never seen anybody else, and nobody would have seen them. Higher google rank, Huh? So you think google is giving points for github, but not for repo.or.cz (the best), or gitorious or any of the others? Proof? nice readme, Doesn't write itself, no matter the VCS. So how does a new VCS magically help? easier collaborating, How exactly easier than today? easier forks Well, I'm not exactly fluent in git (actually I hate its usability, which is next to non-existent), but what's difficult with git checkout -b? etc. Aha. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Github
On Tue, May 15, 2012 at 6:10 AM, Karl Skomski k...@skomski.com wrote: Apart from that: does github have kind of like mob branches by default? Because, quite frankly, that's the only reason I contributed anything, however small, back to tinycc. If it hadn't I still would have had fun for a weekend fixing tcc, justwithout anybody gaining anything from it, as my patches would have never seen anybody else, and nobody would have seen them. Github makes it easy to collaborate with public visible pull requests. http://help.github.com/send-pull-requests/ Higher google rank, Huh? So you think google is giving points for github, but not for repo.or.cz (the best), or gitorious or any of the others? Proof? Github makes it easy for Google to index the important information. Good SEO overall :D nice readme, Doesn't write itself, no matter the VCS. So how does a new VCS magically help? Github makes the README prominent readable on the front-page of the repository. Much less visible with repo.or.cz easier forks Well, I'm not exactly fluent in git (actually I hate its usability, which is next to non-existent), but what's difficult with git checkout -b? Public visible fork networks: https://github.com/libarchive/libarchive/network etc. You could use Travis.CI (http://travis-ci.org/) as continuous integration service. Organization Examples: https://github.com/luvit/luvit https://github.com/libarchive/libarchive Kind regards, Karl Skomski On Tue, May 15, 2012 at 1:28 AM, Michael Matz matz@frakked.de wrote: Hi, On Mon, 14 May 2012, Karl Skomski wrote: Hi, I discovered tinycc some days ago but only today I discovered the current development repository: http://repo.or.cz/w/tinycc.git It's not that easy to find the most-updated tinycc repository. I thought maybe it would be nice to switch the tinycc repository to a github organization? How exactly would that help spreading interest (except in github)? Apart from that: does github have kind of like mob branches by default? Because, quite frankly, that's the only reason I contributed anything, however small, back to tinycc. If it hadn't I still would have had fun for a weekend fixing tcc, just without anybody gaining anything from it, as my patches would have never seen anybody else, and nobody would have seen them. Higher google rank, Huh? So you think google is giving points for github, but not for repo.or.cz (the best), or gitorious or any of the others? Proof? nice readme, Doesn't write itself, no matter the VCS. So how does a new VCS magically help? easier collaborating, How exactly easier than today? easier forks Well, I'm not exactly fluent in git (actually I hate its usability, which is next to non-existent), but what's difficult with git checkout -b? etc. Aha. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel Karl - I like github, but open source groups like tinycc may or may not wish to switch to github. However, there's no reason you couldn't put a fork of tinycc on github and maintain it yourself. When anybody issues a pull request, you could pull it into your fork and then push those changes to the repo.or.cz. When changes get pushed to the mob branch on repo.or.cz, you could pull them in and push them to the github fork. If developers arrive in droves, then you will have all the evidence you need to switch the official repo to github. If they don't, no harm done. In particular, this experiment does not force the current developers to switch their habits, which may be more important than you realize. I thought that a similar switch would really help out the Perl Data Language and created an official fork on github (official because I'm one of the PDL core maintainers), though official releases come from the sourceforge repository. In the months since that happened, I have not gotten a single pull request. I have hopes that this may change, but in truth there just aren't very many developers with spare time to hack on PDL. tinycc may be different, though. David -- Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian Kernighan ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Github
Hi, I discovered tinycc some days ago but only today I discovered the current development repository: http://repo.or.cz/w/tinycc.git It's not that easy to find the most-updated tinycc repository. I thought maybe it would be nice to switch the tinycc repository to a github organization? Higher google rank, nice readme, easier collaborating, easier forks etc. Kind regards, Karl Skomski ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Github
Hi, On Mon, 14 May 2012, Karl Skomski wrote: Hi, I discovered tinycc some days ago but only today I discovered the current development repository: http://repo.or.cz/w/tinycc.git It's not that easy to find the most-updated tinycc repository. I thought maybe it would be nice to switch the tinycc repository to a github organization? How exactly would that help spreading interest (except in github)? Apart from that: does github have kind of like mob branches by default? Because, quite frankly, that's the only reason I contributed anything, however small, back to tinycc. If it hadn't I still would have had fun for a weekend fixing tcc, just without anybody gaining anything from it, as my patches would have never seen anybody else, and nobody would have seen them. Higher google rank, Huh? So you think google is giving points for github, but not for repo.or.cz (the best), or gitorious or any of the others? Proof? nice readme, Doesn't write itself, no matter the VCS. So how does a new VCS magically help? easier collaborating, How exactly easier than today? easier forks Well, I'm not exactly fluent in git (actually I hate its usability, which is next to non-existent), but what's difficult with git checkout -b? etc. Aha. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
