The capability exists, any dev team can take advantage if reqd of it, I am sure many may have in rare occassions. On the remote on the same LAN it will not be any different than debug is for eclipse / VisualStudio in dev. In Insurance, Banking in my experience, it will be the last resort, unless it is critical and there is no other alternative to it but with production data set. As I reiterated the reflection based data gathering that can enabled along with the superb exception handling capability it is something that is leveraged by smalltalk in production ( Unicycle reports in VA) and that is terrific for resolving bugs. Reflection based tools like in Groovy can bring any Java system close to Smalltalk offers also in production as I have done in my work place. On Thu, Apr 24, 2014 at 9:50 AM, askoh <askoh@askoh.com> wrote:

Thanks for reply. Are there cases of Java/Eclipse running in Production? Similarly with VC++ / Visual Studio? They would be very very slow wouldn't they?

I am referring to real use case of live debugging in Production servers. I agree that this capability might not be attractive from point of view of security and safety. But there are insurance and financial companies that use Smalltalk. How do they view this capability? Do they forbid it totally? If they allow it, how do they prevent abuse?

The pros is of course the easy of finding bugs and inspection of states during production.

All the best, Aik-Siong Koh

-- View this message in context: http://forum.world.st/Debugging-in-Production-Servers-tp4756136p4756141.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

The good developers / expert users will not do what you state. The eclipse debug, inspector, watches are very much part of a normal dev cycle in our place with around 100 devs. Even in Smalltalk I have seen less capable developers not exploiting even a fraction of the capability Smalltalk has and depend on loggers / prints to transcripts and lot less use of reflection live to inquire and detect issues faster. The issue I explained is that the capability exists and is not exploited due to process constraints in the industry even for Java, so Smalltalk capability will not be seen as a killer feature per se even if its more flexible and capable. The reflection to dump more logger information is of course most welcome but without adding any performance overhead at runtime except when the error occurs. I would further aver that all the Smalltalk capabilities are highly leveraged in a dev environment and is capable of cutting dev time to one third or even lesser in the hands of an expert. On Thu, Apr 24, 2014 at 11:12 AM, Sven Van Caekenberghe <sven@stfx.eu>wrote:

I am sorry, but I disagree.

Yes, technically, much of what we take for granted is partially possible in most other languages, but it is often hard to use, an add-on, an afterthought. But more important, Java developers even do not use debuggers/inspectors/browsers during development, let alone during production. It's just edit/compile/run/crash - add some print statements and run again. During production its all massive plain logging.

We can dump live stacks with FUEL for example.

On 24 Apr 2014, at 06:01, S Krish <krishnamachari.sudhakar@gmail.com> wrote:

...

One can easily do that with Java / Eclipse or for VC++ / Visual Studio with attach to process. Probably I would reckon these to be more "secure" as industry prefers rather than having live debug capabilities built in to the code delivered or somehow "in-process". I am sure all others as in python, ruby et als will have debug in prod capabilities if reqd.

Javascript with Rhino also can easily allow live debug if the reqd jar is present..

The bigger purchase Smalltalk gives is in reflection that can be leveraged to produce fairly extensive logger reports which no other langauge currently does when fault occurs in production.

I doubt in production the industry is as of now willing to let debug be acceptable specially in Banking domain.

The smalltalk advantages are not translating into business gains per se given the comfort zone of security, safety production systems are wrapped in procedurally.

On Thu, Apr 24, 2014 at 7:39 AM, askoh <askoh@askoh.com> wrote: Smalltalk has the capability of allowing live debugging in production servers. How unique is this capability? What other systems allow that?

Is there a name for such capability? Can we coin one and market it?

What are the pros and cons of having such a capability?

All the best, Aik-Siong Koh

-- View this message in context: http://forum.world.st/Debugging-in-Production-Servers-tp4756136.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

"You do not have to stop while it is running in production and you can change and inspect or even fix the program at will. With all the up's and downs of this approach." Visual Studio can do this with Edit and Continue https://www.youtube.com/watch?v=M6J34B37wUc So the world definitely starts to catch up with Smalltalk. Which can only be a good thing. On Thu, Apr 24, 2014 at 12:26 PM, Torsten Bergmann <astares@gmx.de> wrote:

...

The good developers / expert users will not do what you state. The eclipse debug, inspector, watches >are very much part of a normal dev cycle in our place with around 100 devs.

This is not a problem of being expert or not. In languages like C/C++ you often need to deploy additional debug infos with the runtime (debug symbols in COFF, ...) to get anything useful - which usually is not done by default and needs additional effort if you want to debug in production.

Situation in Java is better from the tooling side because there are no different CPU architectures/instruction sets to consider - just one bytecode set and one JVM. There are nice tools to monitor or debug - but still you have to run the JVM with debug option and debugging from the external side to get the right debugging experience with stepping through the code.

So if you want to debug a web-app in Java the same way you debug at development time you would have to restart your JBoss, Websphere, ... and connect to a specific debug port. That is usually not done in a productive Java app because of a production downtime, limited developer access to it, ... And yes - there is JMX with MBeans, but this is more for monitoring than real debugging.

Comparing inspectors of Eclipse with the inspectors of Smalltalk is comparing apples with oranges. For sure Eclipse has catched up with the IDE and is now also providing inspectors in the UI, also allows evaluating limited expression and good watches.

In Smalltalk you can implement you own inspectors/install them at runtime/change similar to anything other. You can even load new tools and later remove them while running. As we know Smalltalk is different in many regards.

Typical Debugging in other languages is often dealing with the already deceased. Developers work with logging info from production or at a crashed heap dump, etc. Errors are then often reproduced back in the IDE/dev environment.

Unfortunately this often means additional costs and more time before a fix is ready - but the World seems to be satisfied with this already

In Smalltalk you can easily catch specific cases while running. You can easily add code at runtime to check issues (if developer tools are not stripped):

shopItem id = 1234567 ifTrue: [ shopItem inspect ]

and even save a copy of the image at a specific point in time/situation for offline inspection. This is not comparable to a dump because the time to debug in ST tends to zero. While in Java you have to resetup the environment/IDE with the code version, etc.

You can even manipulate and fix data in production easily with Smalltalk:

shopItem id = 1234567 ifTrue: [ shopItem price: 12.3s2 ]

And ... you can also shoot yourself in the foot if not done carefully ;)

Debugging in Smalltalk is different: you do not debug from the outside - you do not have to restart the program and navigate to the point where it happened. If the developer tools are included you can just switch and use them. You also do not have to recompile the whole thing when you found the problem. If there is an easy workaround you can directly apply it to your program and later fix it in the development stream.

So Smalltalk - as a changeable dynamic object system - is here more comparable to a database. You do not have to stop while it is running in production and you can change and inspect or even fix the program at will. With all the up's and downs of this approach.

I doubt that this could/should be marketed as a killer feature. We should keep it as our own little secret.

But it is not only a question of technical feasability: often "production environment" is seen as "holy" and "untouchable" for other reasons like security. So nobody is missing something when the developers do not debug/work directly in production.

Bye T.

On Wed, Apr 23, 2014 at 10:42 PM, Sven Van Caekenberghe <sven@stfx.eu>wrote:

I am sorry, but I disagree.

Yes, technically, much of what we take for granted is partially possible in most other languages, but it is often hard to use, an add-on, an afterthought. But more important, Java developers even do not use debuggers/inspectors/browsers during development, let alone during production. It's just edit/compile/run/crash - add some print statements and run again. During production its all massive plain logging.

And the crucial linguistic difference is Smalltalk's (and LISP's) resume semantics for exceptions vs Java's restart semantics. This difference is that in Smalltalk the exception handler is executed in the context of the exception, allowing the programmer to see the point of error and provide a value with which to /resume/ execution. In Java the exception is delivered in the context of the handler, discarding the execution state that caused the exception, only allowing the program to /restart/ the code that caused the exception, and making investigating the cause of the exception impossible in the current run. We can dump live stacks with FUEL for example.

And this because Smalltalk provides first-class activation records (contexts) /and/ has resume semantics for exceptions.

On 24 Apr 2014, at 06:01, S Krish <krishnamachari.sudhakar@gmail.com> wrote:

...

One can easily do that with Java / Eclipse or for VC++ / Visual Studio with attach to process. Probably I would reckon these to be more "secure" as industry prefers rather than having live debug capabilities built in to the code delivered or somehow "in-process". I am sure all others as in python, ruby et als will have debug in prod capabilities if reqd.

Javascript with Rhino also can easily allow live debug if the reqd jar is present..

The bigger purchase Smalltalk gives is in reflection that can be leveraged to produce fairly extensive logger reports which no other langauge currently does when fault occurs in production.

I doubt in production the industry is as of now willing to let debug be acceptable specially in Banking domain.

The smalltalk advantages are not translating into business gains per se given the comfort zone of security, safety production systems are wrapped in procedurally.

On Thu, Apr 24, 2014 at 7:39 AM, askoh <askoh@askoh.com> wrote: Smalltalk has the capability of allowing live debugging in production servers. How unique is this capability? What other systems allow that?

Is there a name for such capability? Can we coin one and market it?

What are the pros and cons of having such a capability?

All the best, Aik-Siong Koh

-- View this message in context: http://forum.world.st/Debugging-in-Production-Servers-tp4756136.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

-- best, Eliot

On Fri, Apr 25, 2014 at 5:01 AM, askoh <askoh@askoh.com> wrote:

Thanks for all the comments. Let me distilled what I have learned. Correct me if I am wrong.

In Smalltalk: Production environment and development environment are very similar if not identical.

The "environments" on my laptop are the same as my production server? No, one should never count on that.

Runtime and debug modes are identical. So, debugging is instantaneous available.

What about everyone's obsession with shrinking? No one minds a "luxurious" IDE image for development, but most of us seem hell-bent on deploying "minimal" production servers totally stripped of those IDE/debugging luxuries. Now, I'm sure the debugger itself is not stripped, so that's better than nothing, unless running true headless with no way to get a window on the image. We're certainly "able" to do it, but it seems like our desire to shrink might cause need for some balance that provides the best of both worlds..

What I found useful is the ability to patch (compile code) in a running server. That's really a plus when you can't shutdown the server. To me... an interactive debugger in the production environment is not a requirement. Esteban A. Maringolo 2014-04-25 17:38 GMT-03:00 Sebastian Sastre <sebastian@flowingconcept.com>:

On Apr 25, 2014, at 7:01 AM, askoh <askoh@askoh.com> wrote:

Thanks for all the comments. Let me distilled what I have learned. Correct me if I am wrong.

In Smalltalk: Production environment and development environment are very similar if not identical. Runtime and debug modes are identical. So, debugging is instantaneous available. Debugging occurs at the context of the exception itself - not in a handler or somewhere else. Debugger, nah, the whole environment allows doit's, code changes and resumes always. Reflection is constantly available for debugging and logging.

Can we coin a term for these capabilities/properties? Can we define a standard to gauge programming environments?

great question, yeah I can validate that for airflowing.

Those features allowed us to do hot maintenance more than once

At least a couple of times we did it live with a real customer on the other side, it was really great but don’t get too excited, managing a real bug and a real customer's perception both at the same time requires a lot of muscle

sebastian

o/

2014-04-25 17:48 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>:

On 25 Apr 2014, at 22:40, Esteban A. Maringolo <emaringolo@gmail.com> wrote:

...

To me... an interactive debugger in the production environment is not a requirement.

Hmm, but that _is_ a key point: often being able to 'look into a running server' to find or investigate a problem makes all the difference - this interactivity can be much more productive than trying fixes blind.

I value a nice stack dump or a FUEL dump (I haven't tried this), to recreate the context. I understand the fact that "a similar error context" is not the same as "the actual error context", but the truth is if the error is related with I/O (files, network, db...) it is not going to be simple to fix, and maybe the dependent party (a client on the other side) is already gone. That's why I said that, for me (emphasis here), it isn't a requirement, particularly to fix bugs. For live inspection and modifications I DO FIND it valuable. Esteban A. Maringolo

I've quite often opened a REPL on Rails apps in the production environment. You can basically execute everything on the production environment. This is quite useful for checking what's going on (usually a mismatch between your development/staging environment and the production one). Beware that you do not connect to the serving process that your customer is seeing. You just spin a new REPL process with the production settings. And frankly it was usually more than enough to find what you need to fix. On Fri, Apr 25, 2014 at 11:18 PM, Sebastian Sastre < sebastian@flowingconcept.com> wrote:

On Apr 25, 2014, at 5:48 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:

look into a running server' to find or investigate a problem makes all the difference

yeah, I agree. Logs are the last resource and hot debugs are unbeatable. They can cut costs *a lot* when investigating in the real environment where the problem happens and Smalltalk’s debugger is the closest thing to a developer-with-problem dream-tool that the industry can give.