Last month I attended my third annual Bricsys conference. Following on from Munich and Paris, this year’s event was held in London. (For those who remember M’s cheesy hit Pop Musik from 1979, you will notice that Bricsys is holding these events in reverse order, and the next event should therefore be held in New York).
Before we get to the conference itself, I should point out that I preceded it by pinging around Europe doing other Bricsys-related things. I had a couple of days in Berlin with BLADE creator Torsten Moses, preparing our upcoming presentation on BricsCAD’s VLIDE-beating IDE.
We retired to a church building in a forest just outside Berlin and spent a very long day thrashing out a series of demonstrations, down to the last click and keystroke.
Then I shot over to Vienna for another couple of days, where I interviewed the good people at Schrack Seconet about their experiences with their 101 licenses of BricsCAD.
Look out for that when it’s published on the Bricsys Blog in the forthcoming Real World BricsCAD series.
I spent a couple of days in the English countryside rehearsing and preparing for the BLADE presentation, and took this photo which I inserted into my PowerPoint at the last minute.
THE BLADE at Reading Abbey – modernity towers over the ruins of what was once magnificent
Once in London and checked into the hotel, I visited the Bricsys 2018 venue, The Brewery.
It was interesting to check out the preparation that goes into running an event like this. Here, the AV people were testing the individual elements of the huge screen.
Then it was back to the hotel bar where I caught up with lots of old friends, many of whom I knew from previous Autodesk and Bricsys events. In addition to big CAD names like Ralph Grabowski, Randall Newton, R.K. McSwain, Robert Green, Owen Wengerd, Don Strimbu and several Bricsys high-ups, it was great to finally meet the amazing LISP talent Lee Mac.
Steve and a few of the former Autodesk people
It was particularly pleasant to meet up again with the fabulous and talented IPoCs Lynn Allen and Heidi Hewett, who I last met in person at the AutoCAD 2010 launch in San Francisco. The networking that goes on at these events can be just as educational as the presentations, and I certainly learned a few things over a Leffe or two.
Lynn loves Leffes
A dinner for (mostly) press people also proved educational. Despite knowing that some big announcement had been made to the Bricsys employees, we were still none the wiser about exactly what that announcement was. We know now, of course, but right then we were still in the dark.
One thing that was different for me this year is that quite a few people approached me to thank me for my writings on this blog. It was amazing for me to be standing next to somebody way more famous than me, and have people want to shake my hand. Although I found it odd, it’s also gratifying. Thank you to those people who took time out to say that they appreciate what I do.
In the next post in this series, I’ll describe day 1, where the shock announcement was made, and where a user group was born.
I am so thirsty right now….. *sigh*
Hi Steve,
We should go over your experience with the BLADE. I am still struggling to use it in place of the VLIDE. I have a project that has over 100 lisp sub-files, so make use of things like searching within a project, and loading all lisps in a project. The BLADE takes 20 seconds to load the files because it catalogs the functions within and so on. Things that provide advantages on small projects kill the productivity on large ones. I should make a screen video of what I do in the VLIDE. I waited til V19 was well under way as I know Torsten did implement several features I requested so the pain is less than it was. I’d like to see if some polishing can be done though to work well with larger projects. Sounds like the timing may be right.
How do the times compare for:
a) Starting AutoCAD, starting VLIDE and loading a 100 file project; and
b) Starting BricsCAD, starting BLADE and loading a 100 file project?
But if the function indexing time really is a killer on huge projects, maybe Torsten can look at that aspect of performance and/or provide an off switch?
Dear James,
“I have a project that has over 100 lisp sub-files”
probably, that delay in loading is due to the internal caching of “knowledge” from all the un-opened project fiels …
Seems, on slower machines, a Preferences switch to enable/disable such caching woudl improve startup, for your cases …
should not be a problem to implement such a preferences option.
The drawback is, that several advantages of that knowledge will be no longer available then. like detailed informations on the tooltips. the syntax-tips while writing, and cross-checking + verifications by the “Syntax + Variables Check” dialog.
Simply, as all those necessary informations from the un-opened project member files are not available anymore, which means the the functionality + all the advanced features will work in limited way then.
Nevertheless, I think a good idea to implement such a switch …
Besides, a more powerful machine might also help here ? 🙂
many greetings !
P.S. indeed, all your requested features are implemented 🙂
Yes, This IDE idea sounds very Interesting. more Info please. otra fria, por favor?? I once developed a numerical input system for command aliases in OtterCad. I am just now getting in Bricsys, specifically BricsShape. does The Lisp work in BricsShape? how do You access The IDE? or is This The main program, only?? I wrote several hundred LISP in 1990-92, been a while, I am sure it is different, more better by now. Take care. Thank You for any and all additional Information on IDE.
BricsCAD Shape doesn’t have this IDE. LISP is suppressed in the free product. In any of the paid-for versions of BricsCAD from 18.2 onwards, you can enther BLADE or even VLIDE to fire it up.
More on BLADE will be coming, but I have a backlog to work through so it may take a while yet.
Dear James, Dear Steve,
thanks for those hints, about the file content caching …
a)
There was (still is, for the public V19) a logical fault : the file content cache was created, even for those files already open in editor;
this is unintended, and has been fixed internally, for a V19 update later on
b)
I could improve the plain performance for the file content analysis a bit
c)
there will be a setting, how many file(s) to be cached + analysed : all, 0, 10, 20, …. 500;
in generally, the entire file content cache topic will *only* affect those project member files, not being opened in editor.
So I think, a good compsomise then ?
many greetings !