PDA

View Full Version : Is the LW code really that sensitive?



Snosrap
03-14-2018, 07:19 AM
What's up with the all the fixes in LW that breaks previous working features? Is the code structure really that discombobulated? It seems that every patch fixes a lot of previous issues - kudos to the team for that - but breaks about as many different things that got fixed. Is LW really nothing more than a ball of band aids? At this rate nothing new will ever come to LW as so much effort needs to be put in fixing stuff.

MonroePoteet
03-14-2018, 07:49 AM
What's up with the all the fixes in LW that breaks previous working features?...

To what are you referring? Some specific example(s) would be good.

Having worked in very complex code myself, any sort of high-performance system is extremely interwoven and it *is* easy to have side effects from seemingly simple changes. I worked on operating systems internals for quite a while and we spent a large amount of time on "regression testing" to insure these sort of functional side-effects don't happen. My guess is that LWDG does the same type of regression testing but some stuff slips through the cracks.

If you point out the "previous working features" that have stopped working in LW2018.0.2, I'd bet LWDG will fix them ASAP and maybe even add a test or two to the regression test suite.

mTp

raymondtrace
03-14-2018, 10:16 AM
All code is really that sensitive.

03-14-2018, 10:46 AM
yup.

Snosrap
03-14-2018, 11:30 AM
To what are you referring? Some specific example(s) would be good.

Well here for one: http://forums.newtek.com/showthread.php?156431-2018-0-2-spotlight

and here: http://forums.newtek.com/showthread.php?156299-2018-0-2-(build-3065)-Tweak-tool-broken&highlight=tweak

- - - Updated - - -


All code is really that sensitive.

Really?

SBowie
03-14-2018, 11:55 AM
Really?Having worked at several developers over the years, I'd say (with regret) that this often true. A single small change often has unexpected ramifications (especially where, as in our video product lineup, there is a lot of shared code for multiple products). And no amount of in-house testing every comes close to the baptism by fire that occurs when changes propagate to the broader user crowd.

MonroePoteet
03-14-2018, 12:25 PM
Well here for one: http://forums.newtek.com/showthread.php?156431-2018-0-2-spotlight

and here: http://forums.newtek.com/showthread.php?156299-2018-0-2-(build-3065)-Tweak-tool-broken&highlight=tweak

- - - Updated - - -



Really?

OK, thanks for the examples. As I said, I'd bet LWDG will fix them ASAP once reported.

RE: "Really?" - bullet-proof code (or what's called "zero-defect programming") is possible, but it's development is usually very limited in scope, is EXTREMELY SLOW to produce and is (almost) always done from scratch rather than with any sort of legacy code. There really isn't any way to be competitive with zero-defect programming except in situations where failure is unacceptable (e.g. lives are lost at a failure). As well, bullet-proof code tends to be really slow performance-wise because of safety checks (e.g. buffer overflows), parameter checking (untrusted callers and messages), the overhead of object-oriented re-usable code which has a lot of hidden parameter copying and V-table lookups, etc.

Even using zero-defect programming initially, any changes to the "perfect" code, even minor changes, have to go through the same exacting process involving "proofs of correctness" and meta-languages for propagating the "requirements" into implementation.

In the O/S work I did, we did 100% code reviews: every check-in was reviewed by at least two other engineers, often experts (i.e. the original design and author of the code), sent through unit, regression and systems testing and even then the "baptism by fire" in customer environments and usage SBowie refers to might find unforeseen side-effects. As I said, any sort of high-performance code is extremely interwoven and often has dependencies far and wide for correct behavior.

I doubt if LWDG *wants* to break things! :)

mTp

Snosrap
03-14-2018, 12:52 PM
So your saying we are screwed. :) Actually I thought 2018.0.0 was a pretty good release. Then .0.1 came out and it went to he(( , so .0.2 came out and made Modeler usable again but now some other things are borked that were fine in .0.1 - so yeah it's frustrating. Although I imagine it's worse for the devs. :) It seems like certain things in the code would be isolated from other certain things.

SBowie
03-14-2018, 01:01 PM
I think the point people are suggesting is that this is not unique to LW ... it's basically the current state of the software industry at large.

03-14-2018, 01:30 PM
Truly the point is: writing software IS that way, all across the board.

Yes, if we are screwed we've been screwed by everyone that sells us code. Not just LW.

Ever wonder why there aren't 10 or 20 high quality apps of any kind? Programming is hard, especially when you throw thousands of people at it trying to 'break' it.

SBowie
03-14-2018, 01:55 PM
... especially when you throw thousands of people at it trying to 'break' it.This said, we call these people "users" (as opposed, for example, to calling them "breakers") and we really do want them to have the best possible experience. ;)

Snosrap
03-14-2018, 05:35 PM
Well I guess if it's complicated to use it must also be complicated to make. :)

JohnMarchant
03-14-2018, 06:49 PM
So your saying we are screwed. :) Actually I thought 2018.0.0 was a pretty good release. Then .0.1 came out and it went to he(( , so .0.2 came out and made Modeler usable again but now some other things are borked that were fine in .0.1 - so yeah it's frustrating. Although I imagine it's worse for the devs. :) It seems like certain things in the code would be isolated from other certain things.

Something i have noticed about 2018 developement is that the previous versions are no long available in our account. Is there a reason for this apart from wanting us to all use the same version. I have all of the version of 2015/11/10 available. Oops sorry no not all versions of 10 are available, my bad.

shrox
03-14-2018, 09:15 PM
One time, I was at work walking past a programmer's cubicle, and I just glanced at the screen and the code broke immediately.

SBowie
03-14-2018, 10:02 PM
Well I guess if it's complicated to use it must also be complicated to make. :)One of the most complicated parts is keeping it as simple as possible. :)

jwiede
03-15-2018, 12:44 AM
Really?

Not _all code_. But producing code which isn't prone to such high "casual" interconnectedness requires a lot of expertise, and very high levels of engineering discipline applied in all phases of development -- substantially beyond the levels normally seen in application-level development. Such practices (culture, really) is much more common in system software development, and particularly prevalent in high-reliability system software development.

raymondtrace
03-15-2018, 07:38 AM
Something i have noticed about 2018 developement is that the previous versions are no long available in our account. Is there a reason for this apart from wanting us to all use the same version. I have all of the version of 2015/11/10 available. Oops sorry no not all versions of 10 are available, my bad.

Those other versions you can access are official point releases (version.x). Those are more tested and planned.

The updates to 2018 so far have been lesser versions (version.x.x) and have even included separate patches (FiberFX). They are best forgotten. However, they are still on the server if you really need them and dig around.

JohnMarchant
03-15-2018, 08:09 AM
Those other versions you can access are official point releases (version.x). Those are more tested and planned.

The updates to 2018 so far have been lesser versions (version.x.x) and have even included separate patches (FiberFX). They are best forgotten. However, they are still on the server if you really need them and dig around.

Sorry my bad i did not know that at all, i would not know where to dig around anyway. Oh agreed, mostly just bugfixes so we dont want to be running older versions, but for comparison purproses its handy to have them.

beverins
03-15-2018, 08:56 AM
At the school where I work we're always using the latest DCC apps... The grass is just as brown, patchy and full of ticks and burrs as it is on this side of the fence. :boogiedow

For example: Maya's "mayabatch.exe" that acts as the renderfarm's command-line Maya. As far as I know, mayabatch is the only command line app that will actually give you *different* output than the built-in Maya viewer for any renderer... and by "different output" I mean stuff like rendering a T-pose when the character is animated (and shows up in the proper pose in the renderview) or rendering an Alembic cache frame where the geometry is somewhere completely different than where it is supposed to be. This has been a "feature" since I started renderfarming Maya with v2010... It has been greatly improved since those days but even v2018.2 has them and it's just part of the job! :jam:

My new favorite is when companies build their code that relies on some other codeset that they don't control. Quicktime was a good one, since pretty much all the DCC apps we use here used ProRes and suddenly they had to frantically scramble to find workarounds because Apple was like "Quicktime for Windows is deprecated. Bye now".

SBowie
03-15-2018, 09:05 AM
... and suddenly they had to frantically scramble to find workarounds because Apple was like "Quicktime for Windows is deprecated. Bye now".What a pain ... and this was one of the few things (other than marketing) that I was forced to admit they had done quite well.

pauland
03-15-2018, 11:12 AM
As a developer (not for Newtek) I save time by breaking it as I write it, so it saves time for the user.

Legacy code bases are the worst in any company.

I recently had to revisit a project from 2014 and since then my approach to the problem has changed, so you are always left applying sticky patches when maintaing old code. Back in the day they used to rave about the reusability benefits of object-oriented development and as a freelance I never ever saw that in reality at any company I worked at. Today object-orientation is good but development trends are moving to functional programming.

So basically any code-base as old as LW is going to be a pig to work on and it's going to be a pig to find people with the right skillset and enthusiasm to work on what must be obsolete code. I look back in horror at my C and C++ coding days because the languages are so primitive.

I don't use LW so much and compared with the software I am used to using it seems very old-school ( but then again most 3D software looks like that to me ). I think that what LW needs is fresh eyes and ideas from a development architecture point of view and from a user point of view. I'd love to see Newtek take some 2D people and ask them what they'd like to see in a 3D modeller.

Anyway, enough time wasted. I'm sure glad I'm not working on the Newtek codebase.

Rayek
03-15-2018, 12:43 PM
Aye, legacy code isn't only a pig to work with - worse, more often than not it affects core functionality of software and updating / improving those parts turns out to be nigh-on impossible. Lightwave is held back by its neurotic split between Modeler and Layout - a legacy development decision that goes back two decades.

That's been discussed to death, however, and has run its course.

Not many users are aware that the industry standard image editor Photoshop still is hampered by a so-called 16 bit per channel bit depth mode that is actually a 15bpc one. I believe Chris Cox, Photoshop's senior developer, (now retired) when he first added the code base for 16bpc support, he decided it would be easier to calculate with 15bit values, and at the time computers did not have that much processing power nor the RAM to deal with full 16bpc that well.

An additional 16bpc mode related decision was made at that point: when Photoshop is working in 15bpc mode, and the view is zoomed out by ~67% or more, the image pyramid is reduced from a 15bpc to an 8 bit one. This means visible banding unless the image is viewed at 100% or more, and still results in a LOT of confusion among Photoshop users - who attempt to remove the banding by adding noise, etc. Which is completely unnecessary, of course, because it is caused by a "feature" of Photoshop. I suspect the reason for this was again found in the limited video card memory of the time.

While these design decisions were arguably useful at the time to improve performance, they now pose serious problems to anyone working with full-range HDR imagery - and Adobe doesn't mention this anywhere in the manual.

And worse, when a user loads up a full range 16bpc HDR image (not that odd when doing 3d rendering and VFX compositing) Photoshop cuts off the full value range to fit in its 15bpc mode. WITHOUT TELLING THE USER!!! The user open a 16bpc image, which is then silently converted to 15bpc, and when the user saves the file, he is left unaware of the fact that Photoshop wreaked havoc with their files.

It goes without saying this should have been rectified a long time ago. But seeing this is legacy core code that affects most parts of the application, and how calculations are done (because Chris Cox thought it easier to calculate with 15bit values), it remains in place, and would probably require a complete rewrite of Photoshop's 16bpc mode, sending ripples throughout the code base.

Which is why Adobe hasn't fixed it yet. And the question is if they ever will.

That is also why it is generally just as much work, but a much more more controllable and bug-free approach to just do a rewrite, and adhere to modern coding principles/language constructs/code management. Scratch that old C-based code, and start fresh. But as history has shown, rewrite projects are not exactly simple to manage either. For many a commercial project it often meant the end. Between a rock and a hard place, I suppose.

RPSchmidt
03-15-2018, 01:45 PM
"Quicktime for Windows is deprecated. Bye now".

Best thing that ever happened to Windows and non-linear video editing in general, in my opinion. Despised Quicktime with the passion of a thousand burning suns and cringed every time a client asked for a .mov file.

sadkkf
03-15-2018, 02:02 PM
Best thing that ever happened to Windows and non-linear video editing in general, in my opinion. Despised Quicktime with the passion of a thousand burning suns and cringed every time a client asked for a .mov file.

And funny, because I had a Mac client once who couldn't use *any* of my PC formats. He was editing in Final Cut Pro. I ended up giving him an image sequence with a separate audio file.

vncnt
03-15-2018, 02:31 PM
Because of compatibility issues with Quicktime files I'm using AVI more often to exchange videoclips between different software on Win10. I don't understand why AVI isn't being developed anymore. Windows needs a reliable pro exhange format. Fusion can't even export to AVI.

Last week I was surprised to see that I could export to 32bit float WAV. Could that happen to AVI as well?

Bitboy
03-15-2018, 02:56 PM
If you want a good video codec check this out:

https://www.magicyuv.com/

Schwyhart
03-16-2018, 08:02 AM
And funny, because I had a Mac client once who couldn't use *any* of my PC formats. He was editing in Final Cut Pro. I ended up giving him an image sequence with a separate audio file.

I use FCPX everyday and am given PC formats all the time and while they can be difficult (as in the video file isn't as simple as drag and drop) to work with on a Mac, there are ways.
FWIW, the format we use most here is MXF.

sadkkf
03-16-2018, 09:14 AM
I use FCPX everyday and am given PC formats all the time and while they can be difficult (as in the video file isn't as simple as drag and drop) to work with on a Mac, there are ways.
FWIW, the format we use most here is MXF.

I was sure there had to be some common format we could share, but he insisted there wasn't. No matter. Project and client are history.