Viewing profile — marco2357
marco2357
HN member- Joined
- Tue, Jan 20, 2015, 1:53 PM UTC
- HN karma
- 71
- Public activity
- 23 items
- HN profile
- View on Hacker News ↗
About marco2357
No profile information was provided.
Recent public activity
-
comment
Comment #9464399
Yes indeed. We handled goto into do-while statements wrong. Fixed now. Thanks!
-
comment
Comment #9461460
That would be a bug in the translation. We'll investigate. Thanks!
-
comment
Comment #9461235
Hahaha, cool!
-
comment
Comment #9458090
I saw that ;-) The translation is: do { to.set((from = from.shift(1)).get(-1)); } while(--count > 0); which looks correct to me. Hence my question what orodley thinks is wrong.
-
comment
Comment #9458066
Didn't think too much about it since there are many C specific analyzers and tools that do the same. Well, they do it way better. E.g. Valgrind.
-
comment
Comment #9458039
Thank you! But of course a lot of development and money went into our translation framework. So the main aim has to be to make money with it. But as long as we have capacity, we're…
-
comment
Comment #9458019
Can you elaborate on that? What's the C code, the translated Java code and your expected Java code? Thanks!
-
comment
Comment #9458004
Yes, but it's way too limited for replicating what you can do with C pointers. Therefore we wrote our own classes.
-
comment
Comment #9457969
Thanks! malloc() we only optimized for char* so far (there are endless possible optimizations when translating C the way we do). "(double* )malloc(sizeof(double) * 100)" should be …
-
comment
Comment #9457907
Yep, supporting 90% of C took 10% of the time. Or even much less time. Native C libraries (libc, libmath, ...) are just directly used from Java, not translated. Yes, there is a lot…
-
comment
Comment #9457868
Send us an email. We're currently getting overrun with requests but will handle it as fast as possible. Please note that the software needs to be in some public repository (github,…
-
comment
Comment #9457860
Performance is of course lower. But it's impossible to put a number on it. Certainly native calls (printf, scanf, fopen, fread) add a lot of overhead. Also whenever the C memory la…
-
comment
Comment #9457827
Yes. As long as it's non-commercial software.
-
comment
Comment #9457825
True. But also adds a lot of complexity on top of an already very complex translation. But it's certainly something we'll look at in the future (together with supporting Cobol and …
-
comment
Comment #9457802
It's easy to do a minimal prototype when doing research. But writing real translators means to get all the details right. In research we usually don't have the time for that. Trans…
-
comment
Comment #9457734
Only in the form of translating and running dozens of C applications (programs and libraries) and running their testsuites. E.g. libcurl comes with a great extensive testsuite (a p…
-
comment
Comment #9457674
I've seen many research papers on Java -> C translation during my PhD. Some of them came with a prototype tool. But as with previous work on C -> Java translation, none of the tool…
-
comment
Comment #9457190
We translated dozens of open-source projects and decided to list only the interesting ones on the website and upload only the most interesting ones; The ones that are very well kno…
-
comment
Comment #9457161
Main author here. Let me know if you have any questions. I’d be happy to answer.
- story
-
comment
Comment #9443227
There's a Java version of Vim here: https://www.mtsystems.ch/#section2 It's an automatic translation of the C version. Like tomp said 4 hours ago: Like vim, just slower.™
-
comment
Comment #8916934
Why not? There's not that much of a difference between translating C to assembler or a high level language like Java/C#/Go. The main challenge is to make the code readable. But bas…
-
comment
Comment #8916918
Main author of the tool here. If you have questions feel free to contact me: marco.trudel@mtsystems.ch