Re: Fastest JSON parser in the world is a D project
On Friday, October 16, 2015 08:21:32 Jacob Carlborg via Digitalmars-d-announce wrote: > On 2015-10-16 00:14, Jonathan M Davis via Digitalmars-d-announce wrote: > > > I thought that http://code.dlang.org/packages/std_data_json was the json > > implementation we were looking at adding to Phobos. Or did that fall > > through? I haven't paid much attention to the discussion on that, though I > > have used it in one of my own projects. > > Yes, that was the plan. But if a better alternative shows up, should we > look at that as well? Sure, but going from std_data_json as being the candidate to talking about putting this other one in std.experimental seems a bit much. It needs to go through the review process first, and if we're doing that, it doesn't make sense to have two winners. They'll have to duke it out (or be merged), and then the one that wins can go in std.experimental. - Jonathan M Davis
Re: Walter and I talk about D in Romania
On Friday, 16 October 2015 at 06:18:18 UTC, Jacob Carlborg wrote: On 2015-10-15 23:27, Jack Stouffer wrote: Xcode supports D? And I thought that LDC was the only compiler that outputs info for LLDB? No, but it works as good as the underlying debugger that is used. Which in this case is lacking. I interpreted the statement as the actual UI, not the debugger itself. Unfortunately XCode7/lldb doesn't even work for the languages it is meant to support. All versions of XCode7 (including the beta) keeps crashing on me when debugging C++ code running on the ios-simulator. :-( I wish I knew why...
The D Language Foundation is now incorporated
We are pleased to announce that the D Language Foundation is now incorporated with the state of Washington, USA. The foundation's Board of Directors are Walter Bright, Ali Çehreli, and myself. Our initial administrative meeting will take place on Monday. Agenda includes EIN (Employee Identification Number) application, funding, and immediate plans for the foundation. Going forward we're applying for a non-profit status, which is a longer process (3-6 months). We're very excited about the creation of the D Language Foundation and we hold high hopes that it will have a strong positive effect on the D language and community. Andrei
Re: Fastest JSON parser in the world is a D project
On 10/15/15 10:40 PM, Jacob Carlborg wrote: On 2015-10-15 14:51, Johannes Pfau wrote: Doesn't the GPL force everybody _using_ fast.json to also use the GPL license? Yes, it does have that enforcement. Then we'd need to ask Marco if he's willing to relicense the code with Boost. -- Andrei
Re: The D Language Foundation is now incorporated
Andrei Alexandrescu píše v Pá 16. 10. 2015 v 13:04 +0300: > We are pleased to announce that the D Language Foundation is now > incorporated with the state of Washington, USA. The foundation's > Board > of Directors are Walter Bright, Ali Çehreli, and myself. > > Our initial administrative meeting will take place on Monday. Agenda > includes EIN (Employee Identification Number) application, funding, > and > immediate plans for the foundation. > > Going forward we're applying for a non-profit status, which is a > longer > process (3-6 months). > > We're very excited about the creation of the D Language Foundation > and > we hold high hopes that it will have a strong positive effect on the > D > language and community. > > > Andrei > Foundation First foundation, where I am going to donate some money :).
Re: The D Language Foundation is now incorporated
On 16/10/15 11:04 PM, Andrei Alexandrescu wrote: We are pleased to announce that the D Language Foundation is now incorporated with the state of Washington, USA. The foundation's Board of Directors are Walter Bright, Ali Çehreli, and myself. Our initial administrative meeting will take place on Monday. Agenda includes EIN (Employee Identification Number) application, funding, and immediate plans for the foundation. Going forward we're applying for a non-profit status, which is a longer process (3-6 months). We're very excited about the creation of the D Language Foundation and we hold high hopes that it will have a strong positive effect on the D language and community. Andrei Awesome! Congrats.
Re: The D Language Foundation is now incorporated
On Friday, 16 October 2015 at 10:04:36 UTC, Andrei Alexandrescu wrote: We are pleased to announce that the D Language Foundation is now incorporated with the state of Washington, USA. The foundation's Board of Directors are Walter Bright, Ali Çehreli, and myself. Our initial administrative meeting will take place on Monday. Agenda includes EIN (Employee Identification Number) application, funding, and immediate plans for the foundation. Going forward we're applying for a non-profit status, which is a longer process (3-6 months). We're very excited about the creation of the D Language Foundation and we hold high hopes that it will have a strong positive effect on the D language and community. Andrei Congratulations! Looking forward to seeing where this goes :)
Re: Fastest JSON parser in the world is a D project
On Thursday, 15 October 2015 at 22:13:07 UTC, Jonathan M Davis wrote: On Thursday, October 15, 2015 14:51:58 Johannes Pfau via Digitalmars-d-announce wrote: BTW: Is there a reason why the code is GPL licensed? I understand that people might want to use more restrictive licenses, but isn't LGPL a better replacement for GPL when writing library code? Doesn't the GPL force everybody _using_ fast.json to also use the GPL license? See: http://stackoverflow.com/a/10179181/471401 I think that you might be able to link code with various other compatible, open source licenses against it, but you definitely can't link any proprietary code aganist it. Yes, you can. GPL only affects distribution of executables to third party, it doesn't affect services. Maybe you are thinking of AGPL, which also affects services. But even AGPL allows internal usage.
Re: The D Language Foundation is now incorporated
On Friday, 16 October 2015 at 10:04:36 UTC, Andrei Alexandrescu wrote: Andrei I'll keep my fingers crossed! ;)
Re: Fastest JSON parser in the world is a D project
On Wednesday, 14 October 2015 at 07:01:49 UTC, Marco Leise wrote: https://github.com/kostya/benchmarks#json Does fast.json use any non-standard memory allocation patterns or plain simple GC-usage?
Re: The D Language Foundation is now incorporated
On Friday, 16 October 2015 at 10:04:36 UTC, Andrei Alexandrescu wrote: We are pleased to announce that the D Language Foundation is now incorporated with the state of Washington, USA. The foundation's Board of Directors are Walter Bright, Ali Çehreli, and myself. Our initial administrative meeting will take place on Monday. Agenda includes EIN (Employee Identification Number) application, funding, and immediate plans for the foundation. Going forward we're applying for a non-profit status, which is a longer process (3-6 months). We're very excited about the creation of the D Language Foundation and we hold high hopes that it will have a strong positive effect on the D language and community. Andrei Congratulations! I'm very excited about the advantages this can bring to our community! Please keep us posted!
Re: Beta D 2.069.0-b2
On Wednesday, 14 October 2015 at 13:53:17 UTC, Martin Nowak wrote: Second beta for the 2.069.0 release. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.069.0.html Please report any bugs at https://issues.dlang.org -Martin Apart from https://issues.dlang.org/show_bug.cgi?id=15207, I'm seeing a huge +170% speed-up in 32-bit mode for optimized builds vs 2.068, something that is well appreciated :) 64-bit performance is mostly the same. What changed in the backend?
Re: Fastest JSON parser in the world is a D project
On 10/16/15 6:20 AM, Ola Fosheim Grøstad wrote: On Thursday, 15 October 2015 at 22:13:07 UTC, Jonathan M Davis wrote: On Thursday, October 15, 2015 14:51:58 Johannes Pfau via Digitalmars-d-announce wrote: BTW: Is there a reason why the code is GPL licensed? I understand that people might want to use more restrictive licenses, but isn't LGPL a better replacement for GPL when writing library code? Doesn't the GPL force everybody _using_ fast.json to also use the GPL license? See: http://stackoverflow.com/a/10179181/471401 I think that you might be able to link code with various other compatible, open source licenses against it, but you definitely can't link any proprietary code aganist it. Yes, you can. GPL only affects distribution of executables to third party, it doesn't affect services. Maybe you are thinking of AGPL, which also affects services. But even AGPL allows internal usage. No, you cannot link against GPL library without making your code also GPL. "Services" I don't think have anything to do with this, we are talking about binary linking. -Steve
Re: The D Language Foundation is now incorporated
On Friday, 16 October 2015 at 10:04:36 UTC, Andrei Alexandrescu wrote: We are pleased to announce that the D Language Foundation is now incorporated with the state of Washington, USA. The foundation's Board of Directors are Walter Bright, Ali Çehreli, and myself. ... We're very excited about the creation of the D Language Foundation and we hold high hopes that it will have a strong positive effect on the D language and community. Many congratulations! Very much looking forward to what the future of the Foundation will bring. :-)
Re: The D Language Foundation is now incorporated
On Friday, 16 October 2015 at 10:04:36 UTC, Andrei Alexandrescu wrote: We are pleased to announce that the D Language Foundation is now incorporated with the state of Washington, USA. ... Andrei Congratulations! I hope this accelerate many things.
Re: Fastest JSON parser in the world is a D project
Am Thu, 15 Oct 2015 18:17:07 +0200 schrieb Sönke Ludwig : > Am 15.10.2015 um 13:06 schrieb Rory McGuire via Digitalmars-d-announce: > > In browser JSON.serialize is the usual way to serialize JSON values. > > The problem is that on D side if one does deserialization of an object > > or struct. If the types inside the JSON don't match exactly then vibe > > freaks out. > > For float and double fields, the serialization code should actually > accept both, floating point and integer numbers: > > https://github.com/rejectedsoftware/vibe.d/blob/2fffd94d8516cd6f81c75d45a54c655626d36c6b/source/vibe/data/json.d#L1603 > https://github.com/rejectedsoftware/vibe.d/blob/2fffd94d8516cd6f81c75d45a54c655626d36c6b/source/vibe/data/json.d#L1804 > > Do you have a test case for your error? Well it is not an error. Rory originally wrote about conversions between "1" and 1 happening on the browser side. That would mean adding a quirks mode to any well-behaving JSON parser. In this case: "read numbers as strings". Hence I was asking if the data on the client could be fixed, e.g. the json number be turned into a string first before serialization. -- Marco
Re: Fastest JSON parser in the world is a D project
Am Thu, 15 Oct 2015 18:46:12 +0200 schrieb Sönke Ludwig : > Am 14.10.2015 um 09:01 schrieb Marco Leise: > > […] > > stdx.data.json: 2.76s, 207.1Mb (LDC) > > > > Yep, that's right. stdx.data.json's pull parser finally beats > > the dynamic languages with native efficiency. (I used the > > default options here that provide you with an Exception and > > line number on errors.) > > From when are the numbers for stdx.data.json? The latest results for > the pull parser that I know of were faster than RapidJson: > http://forum.dlang.org/post/wlczkjcawyteowjbb...@forum.dlang.org You know, I'm not surprised at the "D new lazy Ldc" result, which is in the ball park figure of what I measured without exceptions & line-numbers, but the Rapid C++ result seems way off compared to kostya's listing. Or maybe that Core i7 doesn't work well with RapidJSON. I used your fork of the benchmark, made some modifications like adding taggedalgebraic and what else was needed to make it compile with vanilla ldc2 0.16.0. Then I removed the flags that disable exceptions and line numbers. Compilation options are the same as for the existing gdc and ldc2 entries. I did not add " -partial-inliner -boundscheck=off -singleobj ". > Judging by the relative numbers, your "fast" result is still a bit > faster, but if that doesn't validate, it's hard to make an objective > comparison. Every value that is read (as opposed to skipped) is validated according to RFC 7159. That includes UTF-8 validation. Full validation (i.e. readJSONFile!validateAll(…);) may add up to 14% overhead here. -- Marco
Re: Fastest JSON parser in the world is a D project
On Friday, 16 October 2015 at 12:53:09 UTC, Steven Schveighoffer wrote: Yes, you can. GPL only affects distribution of executables to third party, it doesn't affect services. Maybe you are thinking of AGPL, which also affects services. But even AGPL allows internal usage. No, you cannot link against GPL library without making your code also GPL. "Services" I don't think have anything to do with this, we are talking about binary linking. There was something called the "server loophole." The language of GPLv2 only requires source to be distributed if the binaries are distributed. The Affero GPL was created to close the loophole, requiring source to be made available even if the binaries aren't distributed. IIRC, GPLv3 requires the same.
Re: Fastest JSON parser in the world is a D project
On 10/16/2015 08:53 AM, Steven Schveighoffer wrote: On 10/16/15 6:20 AM, Ola Fosheim Grøstad wrote: On Thursday, 15 October 2015 at 22:13:07 UTC, Jonathan M Davis wrote: On Thursday, October 15, 2015 14:51:58 Johannes Pfau via Digitalmars-d-announce wrote: BTW: Is there a reason why the code is GPL licensed? I understand that people might want to use more restrictive licenses, but isn't LGPL a better replacement for GPL when writing library code? Doesn't the GPL force everybody _using_ fast.json to also use the GPL license? See: http://stackoverflow.com/a/10179181/471401 I think that you might be able to link code with various other compatible, open source licenses against it, but you definitely can't link any proprietary code aganist it. Yes, you can. GPL only affects distribution of executables to third party, it doesn't affect services. Maybe you are thinking of AGPL, which also affects services. But even AGPL allows internal usage. No, you cannot link against GPL library without making your code also GPL. "Services" I don't think have anything to do with this, we are talking about binary linking. This is the real reason I'm not a huge fan of *GPL. Nobody can understand it!
Re: Fastest JSON parser in the world is a D project
On Friday, 16 October 2015 at 14:05:50 UTC, Mike Parker wrote: On Friday, 16 October 2015 at 12:53:09 UTC, Steven Schveighoffer wrote: Yes, you can. GPL only affects distribution of executables to third party, it doesn't affect services. Maybe you are thinking of AGPL, which also affects services. But even AGPL allows internal usage. No, you cannot link against GPL library without making your code also GPL. "Services" I don't think have anything to do with this, we are talking about binary linking. There was something called the "server loophole." The language of GPLv2 only requires source to be distributed if the binaries are distributed. The Affero GPL was created to close the loophole, requiring source to be made available even if the binaries aren't distributed. IIRC, GPLv3 requires the same. Looks like I got my versions wrong. AGPL is a modified GPLv3. http://www.gnu.org/licenses/why-affero-gpl.en.html
Re: Fastest JSON parser in the world is a D project
Am Fri, 16 Oct 2015 11:09:37 + schrieb Per Nordlöw : > On Wednesday, 14 October 2015 at 07:01:49 UTC, Marco Leise wrote: > > https://github.com/kostya/benchmarks#json > > Does fast.json use any non-standard memory allocation patterns or > plain simple GC-usage? Plain GC. I found no way in D to express something as "borrowed", but the GC removes the ownership question from the picture. That said the only thing that I allocate in this benchmark is the dynamic array of coordinates (1_000_000 * 3 * double.sizeof), which can be replaced by lazily iterating over the array to remove all allocations. Using these lazy techniques for objects too and calling .borrow() instead of .read!string() (which .idups) should allow GC free usage. (Well, except for the one in parseJSON, where I append 16 zero bytes to the JSON string to make it SSE safe.) -- Marco
Re: Fastest JSON parser in the world is a D project
On Friday, 16 October 2015 at 15:07:17 UTC, Ola Fosheim Grøstad wrote: GPL, on the other hand, gives the same right to users of a service. Typo, "AGPL", not "GPL"...
Re: Fastest JSON parser in the world is a D project
On Friday, 16 October 2015 at 12:53:09 UTC, Steven Schveighoffer wrote: No, you cannot link against GPL library without making your code also GPL. "Services" I don't think have anything to do with this, we are talking about binary linking. Yes, you can. GPL is a copyright license which says that if you legally obtain a copy of an executable then you also have the right to the source code and the right to make copies. If you don't hand out an executable then there are no obligations at all, for obvious reasons. GPL, on the other hand, gives the same right to users of a service. https://en.wikipedia.org/wiki/Affero_General_Public_License
Re: Fastest JSON parser in the world is a D project
On 10/16/15 11:07 AM, Ola Fosheim Grøstad wrote: On Friday, 16 October 2015 at 12:53:09 UTC, Steven Schveighoffer wrote: No, you cannot link against GPL library without making your code also GPL. "Services" I don't think have anything to do with this, we are talking about binary linking. Yes, you can. GPL is a copyright license which says that if you legally obtain a copy of an executable then you also have the right to the source code and the right to make copies. If you don't hand out an executable then there are no obligations at all, for obvious reasons. You certainly can link with it, and then your code becomes GPL. you don't have to distribute the binary, but it's still now GPL. The question is, can you link a proprietary licensed piece of software against GPL, while having the proprietary software retain its license, and the answer is no. If you want to say GPL is fine if you only want to provide your software as a service, then that is not an answer to the question. Your software is effectively GPL, but you don't have to distribute the source because you didn't distribute the binary. However, you would have no recourse if you mistakenly provided the binary to someone. Ever. This is a poison pill risk that most companies will not swallow. Please give me a json library that's 10% slower and won't ruin my entire business, thanks. -Steve
Re: Fastest JSON parser in the world is a D project
On Friday, 16 October 2015 at 14:09:13 UTC, Nick Sabalausky wrote: This is the real reason I'm not a huge fan of *GPL. Nobody can understand it! It is really simple!! The basic idea is that people shouldn't have to reverse engineer software they use in order to fix it/modify it, so when you receive software you should get the right to the means to modify it (the source code). In addition GPL also gives you the right to distribute copies (if you want to) so that you can let others enjoy your improved version of the program. It doesn't give the public the right to demand source code to be made available, only owners of legally obtained copies get the right to demand the full source to be available for them. It also does not forbid linking against anything, it requires the copyright holder to grant rights to the receiver of the copy (access to source code and making copies to distribute under the same terms). As long as you keep your modifications/derived works for yourself, the only party that has been granted GPL for the derived work is yourself. One dilemma here is that a company with a million employees is treated like a single entity legally. So big companies can embrace the GPL freely for internal use and services without the redistribution GPL clauses coming into effect, whereas smaller companies that exchange software between them cannot restrict redistribution...
Re: Fastest JSON parser in the world is a D project
On Friday, 16 October 2015 at 15:36:26 UTC, Steven Schveighoffer wrote: You certainly can link with it, and then your code becomes GPL. No, the code is code. It is an artifact. The GPL is a legal document. The legal document says what rights you have to the copy you received and what requirements that follows it. You are allowed to modify it and do anything you want with it that is covered under fair use. This varies between jurisdictions. The license primarily comes into effect when you _distribute_ or _publish_, because the legal precedent for putting restrictions on distribution and publishing is much stronger. And WIPO is much more clear there. So, if you build websites for a third party you can use GPL without redistribution by writing the contract in such a way that the third party is using your service. Meaning, you run the software. So circumventing the GPL isn't all that hard if you want to. The AGPL also affects publishing as a service, so it makes such arrangements much more difficult.
Re: Fastest JSON parser in the world is a D project
On 10/16/15 11:56 AM, Ola Fosheim Grøstad wrote: On Friday, 16 October 2015 at 15:36:26 UTC, Steven Schveighoffer wrote: You certainly can link with it, and then your code becomes GPL. No, the code is code. It is an artifact. The GPL is a legal document. The legal document says what rights you have to the copy you received and what requirements that follows it. You are allowed to modify it and do anything you want with it that is covered under fair use. This varies between jurisdictions. The license primarily comes into effect when you _distribute_ or _publish_, because the legal precedent for putting restrictions on distribution and publishing is much stronger. And WIPO is much more clear there. Right, so what happens when you accidentally distribute it? What license is it under? For example, let's say you have a product that doesn't use JSON. It's proprietary, and you distribute it under a proprietary license. You want to include JSON parsing, so you incorporate this GPL'd library. Then you distribute it under your proprietary license. Recipient says "Wait, you used fast.json! That means this is now GPL, I want the source". Then what? So, if you build websites for a third party you can use GPL without redistribution by writing the contract in such a way that the third party is using your service. Meaning, you run the software. So circumventing the GPL isn't all that hard if you want to. Being able to use GPL on SAAS doesn't satisfy the use case here. This is a compiled library, it can be used in any piece of software. -Steve
Re: Fastest JSON parser in the world is a D project
On Friday, 16 October 2015 at 17:38:01 UTC, Steven Schveighoffer wrote: For example, let's say you have a product that doesn't use JSON. It's proprietary, and you distribute it under a proprietary license. You want to include JSON parsing, so you incorporate this GPL'd library. Then you distribute it under your proprietary license. Recipient says "Wait, you used fast.json! That means this is now GPL, I want the source". Then what? The recipient has no say in this, but the original author can demand that you either stop distribution or purchase a compatible license. Being able to use GPL on SAAS doesn't satisfy the use case here. This is a compiled library, it can be used in any piece of software. My point was that you can use GPLed code in a proprietary service. But you can also ship propritary code separately that the end user links with the GPLed code. It is only when you bundle the two that you get a derived work.
Re: Walter and I talk about D in Romania
On 2015-10-16 09:44, Ola Fosheim Grøstad wrote: Unfortunately XCode7/lldb doesn't even work for the languages it is meant to support. All versions of XCode7 (including the beta) keeps crashing on me when debugging C++ code running on the ios-simulator. :-( I wish I knew why... It's not Swift so... ;) Have you run the debugger inside the debugger? But I guess that is written in C++ as well. Sounds like a serious regression, if it worked before. -- /Jacob Carlborg
Re: Fastest JSON parser in the world is a D project
On 10/16/15 2:24 PM, Ola Fosheim Grøstad wrote: On Friday, 16 October 2015 at 17:38:01 UTC, Steven Schveighoffer wrote: For example, let's say you have a product that doesn't use JSON. It's proprietary, and you distribute it under a proprietary license. You want to include JSON parsing, so you incorporate this GPL'd library. Then you distribute it under your proprietary license. Recipient says "Wait, you used fast.json! That means this is now GPL, I want the source". Then what? The recipient has no say in this, but the original author can demand that you either stop distribution or purchase a compatible license. Exactly my point. Being able to use GPL on SAAS doesn't satisfy the use case here. This is a compiled library, it can be used in any piece of software. My point was that you can use GPLed code in a proprietary service. But you can also ship propritary code separately that the end user links with the GPLed code. It is only when you bundle the two that you get a derived work. And I don't disagree with your point, just that it was not a correct response to "but you definitely can't link any proprietary code aganist [sic] it." -Steve
Re: Fastest JSON parser in the world is a D project
On Friday, 16 October 2015 at 18:53:39 UTC, Steven Schveighoffer wrote: And I don't disagree with your point, just that it was not a correct response to "but you definitely can't link any proprietary code aganist [sic] it." That I don't understand. You can indeed build your executable from a mix of proprietary third party libraries and GPL code, that means you definetively can link. You cannot distribute it together to another third party, but your employer can use it and run a service with it. People attribute way too many limitations to GPL codebases. For many organizations the GPL would be perfectly ok for their software stack.
Re: Fastest JSON parser in the world is a D project
On 10/16/15 3:36 PM, Ola Fosheim Grøstad wrote: On Friday, 16 October 2015 at 18:53:39 UTC, Steven Schveighoffer wrote: And I don't disagree with your point, just that it was not a correct response to "but you definitely can't link any proprietary code aganist [sic] it." That I don't understand. You can indeed build your executable from a mix of proprietary third party libraries and GPL code, that means you definetively can link. You cannot distribute it together to another third party, but your employer can use it and run a service with it. The distribution is implied in the comment. If there isn't distribution, the license taint isn't important, why bring it up? In any case, having a GPL license for a library diminishes its usefulness to proprietary software houses. People attribute way too many limitations to GPL codebases. For many organizations the GPL would be perfectly ok for their software stack. It depends on what you do. Sure, if you are a pure SAAS house, GPL is perfectly fine, but if one day you want to license that as an installable server, you need to re-develop that GPL piece, and make sure your developers never looked at the code. It's not something to take lightly. -Steve
Silicon Valley D Meetup October 22, 2015
We are meeting at Innowest and you are eating pizza! :) Innowest has graciously accepted to be our venue sponsor going forward: http://innowest.org/ Here is the meeting announcement: http://www.meetup.com/D-Lang-Silicon-Valley/events/225452180/ Do you have a regular or lightning talk? Please let us know. And please come to the meeting! :) Thank you, Ali
"Programming in D" code samples
Most of the code samples are now downloadable as a .zip file: http://ddili.org/ders/d.en/index.html Ali
Re: Fastest JSON parser in the world is a D project
On Friday, 16 October 2015 at 21:01:02 UTC, Steven Schveighoffer wrote: The distribution is implied in the comment. If there isn't distribution, the license taint isn't important, why bring it up? That was not implied. You can have a license which is much more limiting, the GPL is fairly liberal. Most software that is written is not for redistribution! In any case, having a GPL license for a library diminishes its usefulness to proprietary software houses. If that's what you you mean, then be explicit about it. It depends on what you do. Sure, if you are a pure SAAS house, GPL is perfectly fine, but if one day you want to license that as an installable server, you need to re-develop that GPL piece, It isn't obvious, you should be able to lease a server without that being considered obtaining a copy? To figure that out you'll need a legal interpretation of the GPL for your jurisdiction. and make sure your developers never looked at the code. It's not something to take lightly. No, having read code in the past does not affect copyright. If you don't translate the GPL code while writing then it isn't a derived work. What you are thinking about is clean room implementation of reverse engineered APIs to hardware where the code only is tiny stubs of machine code that has to be written in a certain way to be compatible.
