search for: flylanguag

Forgot to CC the list, sorry. ----- Forwarded Message ----- > From: Samuel Crow <samuraileumas at yahoo.com> > To: FlyLanguage <flylanguage at gmail.com> > Cc: > Sent: Monday, July 18, 2011 10:40 AM > Subject: Re: [LLVMdev] RTTI gone in 3.0? > > Hi FlyLanguage, > > I thought LLVM disabled RTTI a long time ago.  It was just too slow. > > --Sam > > > ----- Original Message ---...

On Tue, Jul 26, 2011 at 10:56 AM, FlyLanguage <flylanguage at gmail.com> wrote: > #define ASSERT_STRM(cond, args) \ >> if (!(cond)) AssertionFailureStream(__FILE_**_, __LINE__) << args >> >> Note that there's no trailing semicolon, as this is supplied at the >> point where the macro is invoke...

Den 26.07.2011 20:12, skrev Talin: > On Tue, Jul 26, 2011 at 10:56 AM, FlyLanguage <flylanguage at gmail.com > <mailto:flylanguage at gmail.com>> wrote: > > #define ASSERT_STRM(cond, args) \ > if (!(cond)) AssertionFailureStream(__FILE____, __LINE__) > << args > > Note that there's no trailing sem...

> On Sep 1, 2011, at 3:15 PM, FlyLanguage wrote: > >>> Is that really true? I've heard of a lot of LLVM developers using git >>> but it all seems very opaque right now. That's why I hope to get people >>> talking so we can find out where everyone is and go from there. >> >> Yet, there...

On Sep 1, 2011, at 3:15 PM, FlyLanguage wrote: >> Is that really true? I've heard of a lot of LLVM developers using git >> but it all seems very opaque right now. That's why I hope to get people >> talking so we can find out where everyone is and go from there. > > Yet, there's surprisingly little...

By the way, abort() trips the debugger as well - at least, it does in gdb. On Tue, Jul 26, 2011 at 12:12 PM, FlyLanguage <flylanguage at gmail.com> wrote: > Den 26.07.2011 20:12, skrev Talin: > >> On Tue, Jul 26, 2011 at 10:56 AM, FlyLanguage <flylanguage at gmail.com >> <mailto:flylanguage at gmail.com>**> wrote: >> >> #define ASSERT_STRM(cond, args) \ >...

> Or, the front-end of my programming language has to analize the source > code, and convert it to LLVM-IR? Yes

On Sat, Sep 3, 2011 at 8:01 AM, FlyLanguage <flylanguage at gmail.com> wrote: >> On Sep 1, 2011, at 3:15 PM, FlyLanguage wrote: >> >>>> Is that really true?  I've heard of a lot of LLVM developers using git >>>> but it all seems very opaque right now.  That's why I hope to get people >&gt...

On Sep 3, 2011, at 5:01 AM, FlyLanguage wrote: >> On Sep 1, 2011, at 3:15 PM, FlyLanguage wrote: >> >>>> Is that really true? I've heard of a lot of LLVM developers using git >>>> but it all seems very opaque right now. That's why I hope to get people >>>> talking so we can fin...

> I'd also recommand "git pull --rebase" if the goal is to keep history > linear. Note that this has to go with a big, fat, warning, telling the > user that rebasing published history is bad. Rebase is a very good tool > to work with private history, but as soon as you've pushed it to some > place visible by other people, you should stop using it. This is

On Sun, Jul 24, 2011 at 9:54 AM, FlyLanguage <flylanguage at gmail.com> wrote: > Lot of good points. > > > Yep, switching to git would require a lot of work on the project > > maintainers' side. Commit hooks, setting up repositories, rewording > > policies in terms of the commands of the new tools, and tha...

> On Aug 18, 2011, at 10:57 AM, David Greene wrote: >> >> Did the project ever come to a decision about making a transition to >> git? I'm trying to do some longer-term planning and it would be helpful >> to know what the roadmap is. It's stuck on: 1) A misunderstanding that global revision numbers are necessary and that 'git describe' along with

Lot of good points. > Yep, switching to git would require a lot of work on the project > maintainers' side. Commit hooks, setting up repositories, rewording > policies in terms of the commands of the new tools, and that only to > regain the status the project already has - [...] All of which could be done on a mirror, with pushes to svn during the transition. Once it can be

Den 18.07.2011 17:40, skrev Samuel Crow: > Hi FlyLanguage, > > I thought LLVM disabled RTTI a long time ago. It was just too slow. > > --Sam No, it was used a few places until fairly recently at least, and I'm not sure if it's totally gone yet. The custom rtti stuff didn't catch quite all the cases I think. Anyone?

FlyLanguage <flylanguage at gmail.com> writes: >> Have we made any progress on a potential git conversion? AFAIK the only >> outstanding technical issue is the monotonic revision number question. >> Personally, I have no nead for them but others have expressed >> reservation ab...

On 13 July 2011 15:47, fly language <flylanguage at gmail.com> wrote: > I don't really buy the manpower argument. Updating the release doc when > breaking the frigging API is the Right Thing To Do and shouldn't take that > long, when done when the change is fresh in memory. I regularly make small API-breaking changes in the...

Hi all, I know this issue has been discussed over and over again, but I'd like to voice my opinion while 3.0 is still fairly early-ish in the pipeline. So the issue is... API breakage. I understand and agree with the rationale why, namely faster development. But this principle should mean that for each breakage, the dude who makes the breakage should accompany the final commit (or something

On Jul 13, 2011, at 8:09 AM, Jay Foad wrote: > On 13 July 2011 15:47, fly language <flylanguage at gmail.com> wrote: >> I don't really buy the manpower argument. Updating the release doc when >> breaking the frigging API is the Right Thing To Do and shouldn't take that >> long, when done when the change is fresh in memory. > > I regularly make small API-br...

Den 26.07.2011 03:25, skrev Daniel Nicácio: > - Do you know why a OR instruction is used for increments? instead of > using a INC or ADD? You mean "bit_addr++;" ? It's add'ing (+4 due to loop unrolling i guess) %inc.3 = add i32 %0, 4

> #define ASSERT_STRM(cond, args) \ > if (!(cond)) AssertionFailureStream(__FILE__, __LINE__) << args > > Note that there's no trailing semicolon, as this is supplied at the > point where the macro is invoked. > > What do you think? Neat, but inducing a debug trap is even more useful on asserts (optionally).