Anyway, does the license imply that one can't compile GHC's core language and
RTS into objective-c, then compile it with their "so great" software ?
El 26/05/2010, a las 05:51, Ryan Trinkle escribió:
> Hi guys,
>
> I don't think this licensing issue will be a problem for us. It's not clear
If you guys get a nice library layer going between the Java APIs and
Android NDK Haskell, I would very much like it if you could post it up
somewhere. I think the entire community could benefit.
Cheers.
~Liam
On 26 May 2010 19:51, Ryan Trinkle wrote:
> Hi guys,
> I don't think this licensing i
On Wed, May 26, 2010 at 5:51 AM, Ryan Trinkle
wrote:
> Hi guys,
>
> I don't think this licensing issue will be a problem for us. It's not
> clear to me that our game violates this new term, and we certainly don't
> violate any of the principles Steve Jobs used to justify it. If Apple wants
> to
On May 26, 2010, at 10:17 , Pierre-Etienne Meunier wrote:
Anyway, does the license imply that one can't compile GHC's core
language and RTS into objective-c, then compile it with their "so
great" software ?
As I read it, yes; it says that the calls to their APIs must
*originate* from permi
> So, sadly, I think your chances of shipping your a title written in Haskell
> on the iPhone are shot to hell.
+1 for the android version.
Disclaimer: biased google employee
:P
Unfortunately then you get another cockamamie restriction in the whole
JVM vs. tail calls thing... but if you can ge
Well in this case I'd be really interested in seeing how the can tell the
difference, be it only from a simple complexity theoretic point of view ! I
understand they may look for common patterns in their compiler code to tell the
difference between GHC's generated code and theirs, but pretending
wouldn't they just want to have TCO happen during the compilation into
java? why would you want to output java that has recursion?
-Dan
On Wed, May 26, 2010 at 4:17 PM, Evan Laforge wrote:
>> So, sadly, I think your chances of shipping your a title written in Haskell
>> on the iPhone are shot to
On May 26, 2010, at 17:22 , Pierre-Etienne Meunier wrote:
Well in this case I'd be really interested in seeing how the can
tell the difference, be it only from a simple complexity theoretic
point of view ! I understand they may look for common patterns in
their compiler code to tell the diff
On Wed, May 26, 2010 at 01:17:00PM -0700, Evan Laforge wrote:
> Unfortunately then you get another cockamamie restriction in the whole
> JVM vs. tail calls thing... but if you can get around that then lots
> of people will like you a lot.
Working on it... :)
John
--
John Meacham - ⑆rep
On Wed, May 26, 2010 at 5:22 PM, Pierre-Etienne Meunier <
pierreetienne.meun...@gmail.com> wrote:
> Well in this case I'd be really interested in seeing how the can tell the
> difference, be it only from a simple complexity theoretic point of view ! I
> understand they may look for common patterns
On 27/05/2010, at 9:01 AM, Edward Kmett wrote:
> While we can all acknowledge the technical impossibility of identifying the
> original source language of a piece of code...
Uh,
desire:tmp benl$ cat Hello.hs
main = putStr "Hello"
desire:tmp benl$ ghc --make Hello.hs
desire:tmp benl$ strings
Next up, binary obfuscation! Apple already uses these extensively in their
Fairplay code. Surely it isn't against the rules (yet?) to apply them to
your program before submitting it to the store? :P
On Wed, May 26, 2010 at 11:01 PM, Ben Lippmeier wrote:
>
> On 27/05/2010, at 9:01 AM, Edward Kmet
Objects in the heap also have a very regular structure. They all have code
pointers as their first word, which point to info tables that also have a
regular structure [1]. GHC produced code is probably one of the easiest to
identify out of all compiled languages...
http://hackage.haskell.org/t
On Wed, May 26, 2010 at 11:01 PM, Ben Lippmeier wrote:
>> While we can all acknowledge the technical impossibility of identifying the
>> original source language of a piece of code...
>
>
> Uh,
∀p (PieceOfCode(p) -> CanIdentifySourceLanguage(p))
is clearly false, while
∃p (PieceOfCode(p) -> Ca
On May 26, 2010, at 23:23 , C. McCann wrote:
On Wed, May 26, 2010 at 11:01 PM, Ben Lippmeier
wrote:
While we can all acknowledge the technical impossibility of
identifying the original source language of a piece of code...
Uh,
∀p (PieceOfCode(p) -> CanIdentifySourceLanguage(p))
is clearly
On May 27, 2010, at 00:20 , Brandon S. Allbery KF8NH wrote:
On May 26, 2010, at 23:23 , C. McCann wrote:
On Wed, May 26, 2010 at 11:01 PM, Ben Lippmeier
wrote:
While we can all acknowledge the technical impossibility of
identifying the original source language of a piece of code...
Uh,
∀
writes:
> Or maybe this would be a nice research topic: how to generate C code
> that looks like it’s human written…
Nah, that's too easy: just add a sprinkling of buffer overflows,
undefined behavior, and off-by one index errors.
-k
--
If I haven't seen further, it is by standing in the foo
There is a enormous bunch of C code out there on the internet. It is not that
hard to simply take arbitrary commentaries and variable names from it, then
using it to replace GHC's "jjaksh34$"-like variables in the core.
Doing objective-c is a bit harder, as you have to use the objects, or else t
I think some of us may be missing the point about language
identification.
It's not a _technical_ question, it's a _legal_ one.
Apple's lawyers have available to them exactly the kind of instrument
they expect (as lawyers) to have: legal testimony. If you sign up to
the
new rules, you are e
> If this ever gets to court, we may have a criterion imposed on us,
> possibly one as silly as the distinction between programs and
> algorithms said to be made in patent-land.
I really do agree with your post, but what I dont get is why Apple does not
intent anything against George Hotz, who p
On Thu, May 27, 2010 at 08:41:02PM -0400, Pierre-Etienne Meunier wrote:
> > If this ever gets to court, we may have a criterion imposed on us,
> > possibly one as silly as the distinction between programs and
> > algorithms said to be made in patent-land.
>
> I really do agree with your post, but
It's interesting to see what will happen to Unity3D. This great casual
game development tool offers support for exporting to iPhone. They are
hit by Apple's new developer license - because they generate code -
but apparently, apps generated by Unity3D do end up in the Apple
store...
Now.. Unity 3D
On May 26, 2010, at 03:50 , David Virebayre wrote:
On Wed, May 26, 2010 at 9:23 AM, Lyndon Maydwell
wrote:
As a side note, how is this project getting around the language
restrictions apple put in the developer license agreement?
From the project page :
This version uses Apple's official
On Wed, May 26, 2010 at 9:58 AM, Brandon S. Allbery KF8NH
wrote:
> You might want to reread that license agreement. Specifically:
>
> "Applications must be originally written in Objective-C, C, C++, or
> JavaScript as executed by the iPhone OS WebKit engine, and only code
> written in C, C++, an
Of course, given that they have no way of determining that short of asking
for the source code (and hiring another thousand reviewers to read it) or
applying static analysis tools with heuristics to the programs. I really
doubt they do the latter, and the former is unrealistic.
Most people seem to
On May 26, 2010, at 04:14 , David Virebayre wrote:
On Wed, May 26, 2010 at 9:58 AM, Brandon S. Allbery KF8NH
wrote:
You might want to reread that license agreement. Specifically:
Ah, yes. Ouch, that's abusive.
Can they tell the difference though ?
I suspect GHC-generated code is fairly di
Hi guys,
I don't think this licensing issue will be a problem for us. It's not clear
to me that our game violates this new term, and we certainly don't violate
any of the principles Steve Jobs used to justify it. If Apple wants to
reject our app, they already have a variety of excuses at their d
27 matches
Mail list logo
