This project is read-only.

Progress towards a 1.0 release of BooLangStudio

Jun 26, 2008 at 6:01 PM
Edited Jun 26, 2008 at 6:01 PM
An update on progress:

I am just about finished with my work on the PEG-based lexer for BooLangStudio, completely replacing the previous regime, that was built around shoehorning the BooLexer in Boo.Lang.Parser into a role of colorizing lexer for BLS.

I'm happy to say that I am quite pleased with the effort, thus far. I have merged my work into the master branch on my github repo for BooLangStudio and, pending a bit of polish, I am going to start looking towards merging the work of James and Justin (intellisense and msi installer, respectively) into master, as well.

After that, we have some clean-up of misc. bugfix issues and some other functionality to implement (Project settings window for .booproj files, additional project templates, etc) and then we should be ready to release!

Thoughts?
Jul 1, 2008 at 3:29 PM
Great work!

I am back from vacation and will have some time (hopefully) in the coming weeks to work on bugfixes and other high priority issues. I did pull the latest changes from your master and I see that the PegLexer is a boo project which means we have to develop BooLangStudio in the Exp registry hive (for now), I was unable to compile though since the BooLangProject.dll is being used by visual studio and the build process wants to copy this file. I guess this can be worked around by registering BooLangStudio from a different directory then the one you are developing from. Have you figured out a easy way to solve this?




Jul 1, 2008 at 5:59 PM
torkelo,
Glad to have you back!

Regarding your problem:
Yes, what I do is run the "buildinstallzip.bat" file right off of the bat (you need all of the bins to be present in the root/Bin dir, so unless you did a solution clean you should be good...).. take the zip and extract it in another directory outside of the repo.. then run the install.bat file in that directory... this will make it so that BooLangStudio runs out of that separate directory and you can build/clean to your heart's content on the other directory (which contains the repo and all of that)..

.. bear in mind, also, that every time you build boolangstudio in visual studio, because it's an extensibility project.. it's going to overwrite the registry settings that you put out when running the install.bat script.. so you will want to re-run install.bat every time you close your visual studio session and want to restart (ie when installing a new build to test-by-running using the buildinstappzip.bat script)

kind of lame, i know.. but it works... I may merge justin's installer stuff into master sooner, rather than later (as soon as he is satisfied with the quality of it).. and if we do that, we can have a BooLangStudio installed to the main registry hive... so this wouldn't be an issue, anymore.
Jul 1, 2008 at 6:09 PM
That was what I was thinking...

Maybe a nant or powershell script to automate the buildinstappzip.bat , extract zip file, run install.bat would come in handy :)

Jul 8, 2008 at 8:39 PM
An update on progress:

The installer branch in my github repo has been completely switched over! There were several issues associated with getting my changes to BLS integrated with justin's (stupid strongnames, grrrr).. but those have been sorted out.. so you can now install the latest/greatest boolangstudio into the main registry hive, complete with *much* better syntax highlighting.

If you checkout the installer branch, there are some Setup.exe and BooLangStudio.msi files. You can copy those two files out to any directory (or run them in place, if you want), but they are the only two you need. Just run Setup.exe (you can run the msi directly in XP, but have to run Setup.exe in Vista) and it's pretty straight-forward from there.

I'd like if we could test the binaries I have checked in, first and foremost (to verify they work in your env).. then by all means, please test and build/install some binaries you make yourself...

My next bit of work is to push the installer into master (I'd like some feedback from others on the goodness/suckyness of the installer branch, first), then I'd like to work on merging james' intellisense work into the msi-based branch so we can all work on getting the remaining bugs and functionality taken care of ahead of a proper 1.0 release.

Thoughts?
Jul 8, 2008 at 9:04 PM
By the way, the Setup.exe is standalone. You don't need the .msi at all, it should work for Vista and XP.

Also, if you look in the About window for VS you should see the boo plugin in the list, it will say v1.0... I'm not 100% on this but in my desperate attempt to get the plugin working properly I think that the plugin has to be at least v1.0 in order for VS to load it (with the /noVSIP option). Also, if you change any Guids or any of the registration attributes be sure to let me know, most of those values are not automatically set into the build, they will have to be updated in the installer as well. This should be a fairly uncommon task thankfully.
Jul 9, 2008 at 12:12 AM
I decided "what the hell" and took the plunge and pushed the installer branch into master.. so the master branch is now msi-based... may god have mercy upon my soul.

I've also rebased the intellisense branch to master.. so if anyone wants to hack on intellisense, this is a good place to start.
Jul 9, 2008 at 6:04 AM
Great, I will try it out later today.
Jul 10, 2008 at 10:46 AM
Edited Jul 10, 2008 at 10:46 AM
I have begun work on getting project properties to work, nothing fancy, but it would be nice to have Assembly Name and Default Namespace settings for 1.0,  any other setting that should be a high priority?
Jul 10, 2008 at 4:45 PM
torkelo: thanks for taking a look at this.

I think off of the top of my head, it'd be nice to be able to toggle Ducky by default and Whitespace Agnostic mode for the compiler from the project settings. I know that the <Ducky> tag is there and in the .booproj file (something i picked up from sharpdev..) I don't know about WSA mode, though..I guess you would want to look in the boo targets file?
Jul 11, 2008 at 9:51 AM
It was actually simpler than I expected, now AssemblyName, Default Namespace, Ducky and Whitespace settings work. I am not sure how the project properties (set on the ProjectMgr) are translated to MsBuild properties but it works somehow :)

In WSA mode you use the "end" keyword, which doesn't appear to be included in the syntax highlight feature. I guess the intellisense engine also needs to check for WSA mode.

I will be looking at OutputPath setting and also make the Debug/Release configuration work, it appears it isn't working right now.
Jul 11, 2008 at 3:46 PM
The keyword highlighting is part of the BooPegLexer ... the fix is quite trivial, so I will add the 'end' keyword to the list of keywords highlighted by default.. actually, I think i'll just create an issue so that I remember to add that before we release 1.0 :)

Thanks for looking into the output path stuff, as well.. that was gonna be my next idea.
Jul 14, 2008 at 9:38 PM
I have had time to do some work to day and I have some stuff committed to github that is worth pulling (Project properties, delete item from context menu, breakpoint/debugging support).

Maybe it is time soon to try to consolidate and merge everybody's changes into Olson Jefferys master? Maybe it is a good idea to merge as frequent as possible to minimize conflicts :)
Jul 14, 2008 at 11:22 PM
My intellisense-refactor branch on github is pretty solid now, I wouldn't call it feature complete but it's definitely mergable. I second the idea of getting everything together on one branch, I think Jeff's itching to do it too.

There was talk of moving away from Jeff's github account onto a more general BLS one, any further thoughts on this Jeff?

Sounds like you've been doing some cool stuff Torkel, I'm loving you for debugger support! I need to get this stuff checked out.

I'm getting the feeling we're getting closer to 1.0! :)
Jul 15, 2008 at 3:16 AM
James,
Great to hear that you're making excellent progress on the intellisense stuff. Have you been able to package that branch up into a release and verify that it works on other machines?

I say that because I've been following the intellisense-refactor branch pretty closely and trying to verify that the stuff works, but I must be doing something wrong because I can't get the intellisense functionality to work in the msi release... one thing I did do was make sure that Boo.Lang.Parser.dll was packaged up in the msi... I still couldn't get it to work.

I would definately like to get the branches all merged up together, but one barrier is that I've yet to get the intellisense-refactor branch working (that is, actually seeing the functionality in the IDE.. i see that your tests are passing and so on..)

How are you verifying the intellisense functionality? Are you running BLS in the experimental hive?

Anywho, if you could help with this, I'd appreciate it.
Jul 15, 2008 at 8:43 AM
My verification of intellisense has primarily been through tests, and running it in the experimental hive. I'll definitely take a look at packaging it up, see if I can replicate your problem and/or get it working on another machine. There's not much point me doing all this work if it doesn't work on anyone else's machine!
Jul 15, 2008 at 5:37 PM


jagregory wrote:
My verification of intellisense has primarily been through tests, and running it in the experimental hive. I'll definitely take a look at packaging it up, see if I can replicate your problem and/or get it working on another machine. There's not much point me doing all this work if it doesn't work on anyone else's machine!



I can look at the installer packaging and getting intellisense to work also, though I've been very busy lately. The most obvious reasons why it might not be working are if 1 or more assemblies aren't in the bin folder. What assemblies are actually neeeded for intellisense and do you need any sort of other config files, database files or anything else?
Jul 15, 2008 at 11:12 PM
Just an update... I've gone and merged torkelo's work with my master, after verifying the project property dialog, delete item in project and (super cool) debugger breakpoints are working. great stuff!

Additionally.. I've merged this newly updated master branch with james' current intellisense-refactor branch.. and this is present in the repo as the "intellisense" branch, again.
Jul 16, 2008 at 2:35 AM
hmmm... as a follow-up to my earlier enthusiasm regarding merging torkelo's stuff.. i'm noticing a few issues in the intellisense branch (that hopefully are a result of some bad merging that I did)...

1) When you have multiple .booprojs running in one solution.. some projects have the delete options for files, while others don't .. It's not reliable exactly when/where this happens (then again, I haven't done much testing on it)..

2) I'm having problems adding new files to a project, getting either a "File with that key already exists" error in the IDE or something like "invalid parameter: index" .. I might check this out in the debugger.. hopefully it's an issue with my merge and not a problem with the underlying implementations.

As noted, I'm observing this in the latest revision in the 'intellisense' branch on my repo, feel free to take a peek.
Jul 16, 2008 at 8:55 AM
Justin, Jeff: I had a quick play with the installer in my intellisense-refactor branch last night, and it's behaving a bit strangely. I added the Boo.Lang.Parser.dll that was needed by intellisense into the installer, but no matter what I did I couldn't get the installer to package the new binaries.

I've got more time to play with it tonight, so I'll have a proper look see if I can get it building the installer properly.
Jul 16, 2008 at 9:09 AM
Great Olson, I will test the intellisense branch also.

I think it would be good to have a common github repos, where we can all push changes to, I like some of the git stuff, but I miss the ability to quickly and easily get updates from other core contributes as you get from a centralized SVN setup. Having us four work in separate remote repositories for weeks feels like it slows things down a little :) I know you can pull changes from others, but it feels counter productive to have to do that manually for the main developers on a project.


Jul 16, 2008 at 9:52 AM
I found one bug in the intellisense branch:

The AddCATIDMapping calls in BooProjectNode has been moved from the constructor into the Object property accessor, this causes the AddCATIDMapping being called more than once which results in a "type already exists" exception (which is happening during intellisense lookup which causes the intellisense to stop working). Is there a reason why this was moved? In IronPython they have these calls in a InitializeCATIDs method which is called from the constructor.

Anyway, I fixed that (localy only for now) and then the intellisense started working, and it worked pretty good, nice work James!



Jul 16, 2008 at 10:23 AM
Nice find! Sounds like a merge issue... could be wrong though.

I'm glad intellisense is working for you, I was beginning to think that I was imagining it working ;)
Jul 16, 2008 at 2:52 PM
thanks for the help with that, torkelo... that issue you describe in BooProjectNode was my fault, it was one of the merge conflicts that I had to sort out. I'll fix that in my local copy and see if that fixes things.

Also, regarding the central github account, it's something that I'd like to do in the near future. Either that, or we can consider moving BooLangStudio into Subversion or something like that? I really like git for working locally (and as the one who set this thing up, I guess it was an indulgence I was allowed to enjoy), but I understand that other team members might not be super-enthused with the git model... so perhaps we can consider other avenues, going forward. I would like us to sort out current issues in our diveregent branches (hopefully working on this intellisense branch and merging that to master.. then hacking from there) before we consider a move of that sort..
Jul 16, 2008 at 5:48 PM


olsonjeffery wrote:
thanks for the help with that, torkelo... that issue you describe in BooProjectNode was my fault, it was one of the merge conflicts that I had to sort out. I'll fix that in my local copy and see if that fixes things.

Also, regarding the central github account, it's something that I'd like to do in the near future. Either that, or we can consider moving BooLangStudio into Subversion or something like that? I really like git for working locally (and as the one who set this thing up, I guess it was an indulgence I was allowed to enjoy), but I understand that other team members might not be super-enthused with the git model... so perhaps we can consider other avenues, going forward. I would like us to sort out current issues in our diveregent branches (hopefully working on this intellisense branch and merging that to master.. then hacking from there) before we consider a move of that sort..


Just for the record (since I'm the one who has complained the most about it) since I've started using git I have learned to appreciate it more. It does genuinely have some good ideas behind it, with the local branches and being able to selectively pull and push, it's pretty cool. So my criticisms will be restricted to only two right now:
  1. Tooling. Command line? Seriously? I have a hard enough time remembering my passwords not to mention 1001 new commands and parameters and all of the crazy processes and procedures. That UI tool it comes with is nearly useless.
  2. Heavy weight. For a small team it seems like a lot of hoops to jump through to pull in other peoples changes, perhaps this would be changed by simply having a common branch for us to all work on together, perhaps not. You can still branch in SVN or TFS to avoid doing experimental work in the TRUNK if that's the main thing we're trying to avoid.
Sorry to be a stick in the mud :(
Jul 17, 2008 at 8:19 AM
I think git is very interesting, I definitely like the branch and merge stuff, and the opportunity for everyone to fork the repository on github and start working is very nice, and I like the github network graph.

But the usability is very low, at least compared to TortoiseSVN (best SCM client on the planet). And the number #2 reason that Justin mentioned above is probably my biggest issue. I think it is a good idea to either have a central github repos or move to subversion.



Jul 17, 2008 at 9:34 AM
Guys, I've made a thread for discussing our source control. Everyone drop your comments in there and we'll make a decision.

http://www.codeplex.com/BooLangStudio/Thread/View.aspx?ThreadId=31643
Aug 12, 2008 at 8:32 AM

Is everything merged? what needs to happen before a release? More testing?
Aug 12, 2008 at 10:02 AM
I don't think its been merged yet.

On Tue, Aug 12, 2008 at 9:54 AM, torkelo <notifications@codeplex.com> wrote:

From: torkelo


Is everything merged? what needs to happen before a release? More testing?

Read the full discussion online.

To add a post to this discussion, reply to this email (BooLangStudio@discussions.codeplex.com)

To start a new discussion for this project, email BooLangStudio@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Aug 12, 2008 at 2:33 PM
I have not begun work on any merging, for two reasons:

1) I've just started a new job
2) My new workstation, where I was going to try out the new branch and
do some dogfooding, is a 64bit Server 2008 install, so I'm running
into the 64bit-mode booc.exe getting handed 32bit system assemblies by
msbuild. I'm contemplating patching the booc.exe with corflags as
discussed in some threads on the boolang list. I believe this is a
problem we can address quite directly in our distro by the method
above (patching booc.exe will become a part of the process of
upgrading the boo assembles/executables from source in the future). I
will document this process on the wiki so if anyone is curious on how
to do this...

The two issues are blocking me from getting in and doing any testing
on james' work (his previous work, which I have reviewed, has been
quite promising and he has addressed some issues I had in recent
checkins, I believe), which is something I'd like to do before doing a
merge.

If another team member wants to take a crack at a merge, I'm fine with that.

Also, I'd like to resolve the divergent branch problem before we start
talking about a source control switch.

Cheers,
Jeff

On Tue, Aug 12, 2008 at 3:54 AM, [email removed] wrote:
> From: jagregory
>
> I don't think its been merged yet.
>
> On Tue, Aug 12, 2008 at 9:54 AM, torkelo <[email removed]> wrote:
>
> From: torkelo
>
> Is everything merged? what needs to happen before a release? More testing?
>
> Read the full discussion online.
>
> To add a post to this discussion, reply to this email
> ([email removed])
>
> To start a new discussion for this project, email
> [email removed]
>
> You are receiving this email because you subscribed to this discussion on
> CodePlex. You can unsubscribe or change your settings on codePlex.com.
>
> Please note: Images and attachments will be removed from emails. Any posts
> to this discussion will also be available online at codeplex.com
>
> Read the full discussion online.
>
> To add a post to this discussion, reply to this email
> ([email removed])
>
> To start a new discussion for this project, email
> [email removed]
>
> You are receiving this email because you subscribed to this discussion on
> CodePlex. You can unsubscribe or change your settings on codePlex.com.
>
> Please note: Images and attachments will be removed from emails. Any posts
> to this discussion will also be available online at codeplex.com
Aug 12, 2008 at 4:01 PM
I have checked in a bunch of small things to my branch. Resolving the, always save on opening a boo project file, which means the BooBinPath does not automatically appear in the project file anymore either (though it works fine if it is there already).

I also updated the icons so they are more consistent and look good.
Aug 14, 2008 at 5:05 PM
Great news everyone!

I just pushed a massive change into my master branch, consisting of:

- Torkelo's work on debugger breakpoints and a proper project property
page for .booproj
- Justin's cleanup of BooBinPath behavior in project files and tweaks
to icons, project templates, the installer, etc
- This is, also, the debut of James' intellisense work on the master branch :)
- I've updated the boo dependencies/compiler to revision 3035, which
will give us some more generics goodness.
- In addition to the rev upgrade, i've also patched booc.exe with
corflags (and resigned) so that booc.exe is forced into 32bit mode,
due to an issue with msbuild always being in 32bit mode, as well.. so
it hands booc.exe the 32bit mixed-mode System.dll which will cause all
builds to fail in 64bit windows, since booc.exe will run in the
system's arch by default.

I've verified the following functionality:

- debugger breakpoints work
- property page works (only in the main hive.. doesn't work in debug)
- new icons
- you don't have to constantly save boo projects anymore, even if you
made no changes (a big thanks to justin for tracking this down)
- We can build on a 64bit env (thanks to the boolang list for previous
discussion of this). I went ahead and pulled the trigger on this one..
so if there are people who MUST have 64bit booc.exe, we can talk about
a more robust solution to this issue.
- Intellisense works as do the method summaries with the following
exceptions that I'm sure James is aware of:
1: no intellisense for self
2: no intellisense for arguments to methods, ie:
def foo(bar as string):
bar. <--- no intellisense
interestingly, you do get intellisense for local variables in the
scope.. so declaring a local var and assigning the arg to it would get
you that intellisense.. this should be implemented, though.
3: when showing method summary, doesn't show overloads (I believe
James mentioned this one, previously)


Anyways, I'd like to avoid the wide branch divergence, if possible,
and have everyone start hacking from a fresh checkout of this branch
and avoid merging it into your local repo (looking at the github
revision graph was very discouraging as I got ready to do this merge)

Also, we're about at a point where we can start talking about
alternative source control solutions. I kinda kept this under my hat,
but I have already registered boolangstudio at google code, so we have
a free svn repo (before I decided to use git :)

That being said, I just dealt with this epic merge and the clean-up it
entailed, so give me a few days/weeks/months to recover before we talk
about svn.

Cheers,
Jeff
Aug 14, 2008 at 6:53 PM
Awesome.

One question, if we're working on your branch rather than a merged clone where will we push changes? Should we just not push the changes and wait for the SVN repository? Or would you like our public keys so we can all push to the same repository?

Also, codeplex has a SVN bridge so you can check directly into TFS using svn (tortoise or whatever) if that appeals to you. There is something to be said for having the code in the same place as the releases, discussions, wiki's etc.
Aug 14, 2008 at 10:33 PM
Nice work Jeff! I don't have much time to talk right now. The biggest thing that I haven't implemented with intellisense is the overloads for methods (as you said), and I haven't done this yet because it needs to be tied into the lexer. The lexer needs to raise certain events when it encounters methods, otherwise they won't be accessible as overloads in the GetMethods method of BooScope. Due to our branches being quite different at the time, I didn't want to implement this while you were busy implementing the Pegs lexer.

I'm going to remove my intellisense-refactor branch then rebase my master to yours.

On Thu, Aug 14, 2008 at 5:54 PM, olsonjeffery <notifications@codeplex.com> wrote:

From: olsonjeffery

Great news everyone!

I just pushed a massive change into my master branch, consisting of:

- Torkelo's work on debugger breakpoints and a proper project property
page for .booproj
- Justin's cleanup of BooBinPath behavior in project files and tweaks
to icons, project templates, the installer, etc
- This is, also, the debut of James' intellisense work on the master branch :)
- I've updated the boo dependencies/compiler to revision 3035, which
will give us some more generics goodness.
- In addition to the rev upgrade, i've also patched booc.exe with
corflags (and resigned) so that booc.exe is forced into 32bit mode,
due to an issue with msbuild always being in 32bit mode, as well.. so
it hands booc.exe the 32bit mixed-mode System.dll which will cause all
builds to fail in 64bit windows, since booc.exe will run in the
system's arch by default.

I've verified the following functionality:

- debugger breakpoints work
- property page works (only in the main hive.. doesn't work in debug)
- new icons
- you don't have to constantly save boo projects anymore, even if you
made no changes (a big thanks to justin for tracking this down)
- We can build on a 64bit env (thanks to the boolang list for previous
discussion of this). I went ahead and pulled the trigger on this one..
so if there are people who MUST have 64bit booc.exe, we can talk about
a more robust solution to this issue.
- Intellisense works as do the method summaries with the following
exceptions that I'm sure James is aware of:
1: no intellisense for self
2: no intellisense for arguments to methods, ie:
def foo(bar as string):
bar. <--- no intellisense
interestingly, you do get intellisense for local variables in the
scope.. so declaring a local var and assigning the arg to it would get
you that intellisense.. this should be implemented, though.
3: when showing method summary, doesn't show overloads (I believe
James mentioned this one, previously)


Anyways, I'd like to avoid the wide branch divergence, if possible,
and have everyone start hacking from a fresh checkout of this branch
and avoid merging it into your local repo (looking at the github
revision graph was very discouraging as I got ready to do this merge)

Also, we're about at a point where we can start talking about
alternative source control solutions. I kinda kept this under my hat,
but I have already registered boolangstudio at google code, so we have
a free svn repo (before I decided to use git :)

That being said, I just dealt with this epic merge and the clean-up it
entailed, so give me a few days/weeks/months to recover before we talk
about svn.

Cheers,
Jeff

Read the full discussion online.

To add a post to this discussion, reply to this email (BooLangStudio@discussions.codeplex.com)

To start a new discussion for this project, email BooLangStudio@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Aug 14, 2008 at 10:33 PM
So if we're hacking on this branch rather than a merged clone of it, where will we push our changes? Are you wanting us to just not commit until we move to SVN? Or do you want our public keys so we can all push into the same repository?


On Thu, Aug 14, 2008 at 11:54 AM, olsonjeffery <notifications@codeplex.com> wrote:

From: olsonjeffery

Great news everyone!

I just pushed a massive change into my master branch, consisting of:

- Torkelo's work on debugger breakpoints and a proper project property
page for .booproj
- Justin's cleanup of BooBinPath behavior in project files and tweaks
to icons, project templates, the installer, etc
- This is, also, the debut of James' intellisense work on the master branch :)
- I've updated the boo dependencies/compiler to revision 3035, which
will give us some more generics goodness.
- In addition to the rev upgrade, i've also patched booc.exe with
corflags (and resigned) so that booc.exe is forced into 32bit mode,
due to an issue with msbuild always being in 32bit mode, as well.. so
it hands booc.exe the 32bit mixed-mode System.dll which will cause all
builds to fail in 64bit windows, since booc.exe will run in the
system's arch by default.

I've verified the following functionality:

- debugger breakpoints work
- property page works (only in the main hive.. doesn't work in debug)
- new icons
- you don't have to constantly save boo projects anymore, even if you
made no changes (a big thanks to justin for tracking this down)
- We can build on a 64bit env (thanks to the boolang list for previous
discussion of this). I went ahead and pulled the trigger on this one..
so if there are people who MUST have 64bit booc.exe, we can talk about
a more robust solution to this issue.
- Intellisense works as do the method summaries with the following
exceptions that I'm sure James is aware of:
1: no intellisense for self
2: no intellisense for arguments to methods, ie:
def foo(bar as string):
bar. <--- no intellisense
interestingly, you do get intellisense for local variables in the
scope.. so declaring a local var and assigning the arg to it would get
you that intellisense.. this should be implemented, though.
3: when showing method summary, doesn't show overloads (I believe
James mentioned this one, previously)


Anyways, I'd like to avoid the wide branch divergence, if possible,
and have everyone start hacking from a fresh checkout of this branch
and avoid merging it into your local repo (looking at the github
revision graph was very discouraging as I got ready to do this merge)

Also, we're about at a point where we can start talking about
alternative source control solutions. I kinda kept this under my hat,
but I have already registered boolangstudio at google code, so we have
a free svn repo (before I decided to use git :)

That being said, I just dealt with this epic merge and the clean-up it
entailed, so give me a few days/weeks/months to recover before we talk
about svn.

Cheers,
Jeff

Read the full discussion online.

To add a post to this discussion, reply to this email (BooLangStudio@discussions.codeplex.com)

To start a new discussion for this project, email BooLangStudio@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




--
Justin Chase
http://www.justnbusiness.com
Aug 14, 2008 at 10:45 PM
No TFS.

On Thu, Aug 14, 2008 at 10:39 PM, justinc <notifications@codeplex.com> wrote:

From: justinc

Awesome.

One question, if we're working on your branch rather than a merged clone where will we push changes? Should we just not push the changes and wait for the SVN repository? Or would you like our public keys so we can all push to the same repository?

Also, codeplex has a SVN bridge so you can check directly into TFS using svn (tortoise or whatever) if that appeals to you. There is something to be said for having the code in the same place as the releases, discussions, wiki's etc.

Read the full discussion online.

To add a post to this discussion, reply to this email (BooLangStudio@discussions.codeplex.com)

To start a new discussion for this project, email BooLangStudio@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Aug 15, 2008 at 12:24 PM
No TFS :) , SvnBridge works okey but....

I think having a common master git repository where we can commit changes to, or an SVN repository would be great.
Aug 15, 2008 at 12:49 PM
I'm pro Git, so I'd prefer to go that route, but honestly, I don't mind about using SVN on googlecode either. I already use it for a couple of other projects, so it's no trouble to me.
Aug 22, 2008 at 4:32 PM
just a quick update... I found an issue with Boo.Pegs, where a change
to Boo.Lang.List caused the build of the boolangstudio source to fail
in BooPegLexer... i fixed this by rebuilding boo-extensions from
source using boo rev3035.

The changes are pushed to master. Also, today I'm going to release a
"1.0 alpha1" binary and source release to get it out there and get
some more eyes on it. Additionally, this will give -anyone- who wants
to hack on BLS the ability to do so. What I call the "bootstrap" issue
discussed in the other discussion with nrstrott is/was a major
roadblock to outsiders coming in and contributing. Getting a binary
release out there based on our latest efforts should go a long way to
remove it.

Also, I notice that james rebased from my master. You'll need to
rebase on my latest changes if you want to be able to build, based on
the aforementioned issue.