[vwnc] Conditional Sourcecode - Please

Does anyone know of an existing solution for conditional source code  
(preprocessing)? I very much need a way to provide different method  
sources for different development phases and product variants.

Current workarounds are:
1) Logging methods that mute output depending on development preferences
2) Countless ifTrue:ifFalse: branching according to product preferences

These however don't cut it. The strings for debug messages are  
assembled regardless whether the output is needed or not (1). This  
results in unnecessary garbage and message sends. The situation gets  
worst, when the messages use macro subsitution. Workaround (2)  
introduces a structure to the code that is not related to its  
semantics. Both workarounds query a global state, which again causes  
additional message sends and shared variable accesses and whatnot,  
even when not needed.

Conditional sources greatly support different builds of a product  
(freeware, trial, standard, professional, development). Using the  
above workarounds is not a satisfactory solution, because the disabled  
code is still compiled and shipping with the product where it shouldn't.

Any ideas? I can imagine a rather straightforward implementation  
(through automatically inserted comments), but first want to know if  
there is already something available to use.

Andre

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

I don't have a conditional source solution, but you note that
debug messages are built even if no debugging -- we just put the
debug trace in a block and the handler just sends 'value' -- lets us
do anything we want in debug trace code.

Andre Schnoor wrote:
--
Dennis Smith                         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              sip:[hidden email]
Canada         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

While not as adaptable as conditional source code, you can
create logging probes that insert themselves at the desired
code locations. You can make the insertion point adaptable
to change by incorporating a pattern search to find the
insertion point.

Terry
 
===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Indeed, the following might work nicely I imagine,

['unexpected value of blah'] log: #critical.
['database pid is <1s>' expandMacrosWith: pid] log: #info.

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Dennis Smith
Sent: Monday, August 17, 2009 8:40 AM
To: Andre Schnoor
Cc: VW NC
Subject: Re: [vwnc] Conditional Sourcecode - Please

I don't have a conditional source solution, but you note that
debug messages are built even if no debugging -- we just put the
debug trace in a block and the handler just sends 'value' -- lets us
do anything we want in debug trace code.

Andre Schnoor wrote:
> Does anyone know of an existing solution for conditional source code  
> (preprocessing)? I very much need a way to provide different method  
> sources for different development phases and product variants.
>
> Current workarounds are:
> 1) Logging methods that mute output depending on development
preferences
> 2) Countless ifTrue:ifFalse: branching according to product
preferences
> code is still compiled and shipping with the product where it
shouldn't.
--
Dennis Smith                         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              sip:[hidden email]
Canada         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hi Andre,

 > Does anyone know of an existing solution for conditional source code
 > (preprocessing)? I very much need a way to provide different method
 > sources for different development phases and product variants.

I faintly remember a package (I guess it was about vw2.1) where you
could write self assert: booleanExpression code in your methods.
Depending on an image wide flag, these assertions would have been
executed or not.
The trick was, that the assert package modified the compiler to not
create any bytecode, if the assertions were disabled and if the flag
was toggled to recompile all methods with such invocations. This way
nothing would have been executed in a production environment (because
there was no code) and in development you could even switch it on and off.

But, the public repository came up with nothing like that. Maybe the
creative naming conventions kept me from finding it, maybe it is not
supported anymore, maybe someone else knows about this.

Regards
   Jan
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Wouldn't you actually want to be able to change logging status of a
running production application? The message send to a blog that would
check if logging is enabled carries trivial cost and only in limited
circumstances would that have any impact on anything that matters, but
without knowing Andre's motivation it's hard to say it would apply in
his case.

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Jan Weerts
Sent: Monday, August 17, 2009 9:15 AM
To: Andre Schnoor
Cc: VW NC
Subject: Re: [vwnc] Conditional Sourcecode - Please

Hi Andre,

 > Does anyone know of an existing solution for conditional source code
 > (preprocessing)? I very much need a way to provide different method
 > sources for different development phases and product variants.

I faintly remember a package (I guess it was about vw2.1) where you
could write self assert: booleanExpression code in your methods.
Depending on an image wide flag, these assertions would have been
executed or not.
The trick was, that the assert package modified the compiler to not
create any bytecode, if the assertions were disabled and if the flag
was toggled to recompile all methods with such invocations. This way
nothing would have been executed in a production environment (because
there was no code) and in development you could even switch it on and
off.

But, the public repository came up with nothing like that. Maybe the
creative naming conventions kept me from finding it, maybe it is not
supported anymore, maybe someone else knows about this.

Regards
   Jan
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Am 17.08.2009 um 17:49 schrieb Boris Popov:

> Indeed, the following might work nicely I imagine,
>
> ['unexpected value of blah'] log: #critical.
> ['database pid is <1s>' expandMacrosWith: pid] log: #info.

Thanks Boris and everyone who replied so far (that was really a quick  
response).

The block solution would be doable for logging, I think. That long  
forgotten solution based on a compiler modification sounds  
interesting. Probably similar to the inline handling of  
ifTrue:ifFalse, I would guess.

A major concern for me is that I don't want disabled code to ship with  
a product, whether it will be executed or not doesn't matter. The code  
must not be present in the image. Currently I use a special image  
stripping that nukes methods tagged with a certain pragma. This  
however only works at the method level.

André


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

You could just run a rewrite rule that stripped out all sends of #log: to a block when you package the image.

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4


-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Monday, August 17, 2009 10:17 AM
To: Boris Popov
Cc: Dennis Smith; VW NC
Subject: Re: [vwnc] Conditional Sourcecode - Please


Am 17.08.2009 um 17:49 schrieb Boris Popov:

> Indeed, the following might work nicely I imagine,
>
> ['unexpected value of blah'] log: #critical.
> ['database pid is <1s>' expandMacrosWith: pid] log: #info.

Thanks Boris and everyone who replied so far (that was really a quick  
response).

The block solution would be doable for logging, I think. That long  
forgotten solution based on a compiler modification sounds  
interesting. Probably similar to the inline handling of  
ifTrue:ifFalse, I would guess.

A major concern for me is that I don't want disabled code to ship with  
a product, whether it will be executed or not doesn't matter. The code  
must not be present in the image. Currently I use a special image  
stripping that nukes methods tagged with a certain pragma. This  
however only works at the method level.

André


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

My rewrite skillz might be a bit rusty, but something like the following should do the trick,

Search for:
        ``@.stmts1.
        [``@.stmts2] log: `#literal.
        ``@.stmts3.

Replace with:
        ``@.stmts1.
        ``@.stmts3.

Cheers,

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Boris Popov
Sent: Monday, August 17, 2009 10:18 AM
To: [hidden email]
Cc: VW NC
Subject: Re: [vwnc] Conditional Sourcecode - Please

You could just run a rewrite rule that stripped out all sends of #log: to a block when you package the image.

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4


-----Original Message-----
From: [hidden email] [mailto:[hidden email]]
Sent: Monday, August 17, 2009 10:17 AM
To: Boris Popov
Cc: Dennis Smith; VW NC
Subject: Re: [vwnc] Conditional Sourcecode - Please


Am 17.08.2009 um 17:49 schrieb Boris Popov:

> Indeed, the following might work nicely I imagine,
>
> ['unexpected value of blah'] log: #critical.
> ['database pid is <1s>' expandMacrosWith: pid] log: #info.

Thanks Boris and everyone who replied so far (that was really a quick  
response).

The block solution would be doable for logging, I think. That long  
forgotten solution based on a compiler modification sounds  
interesting. Probably similar to the inline handling of  
ifTrue:ifFalse, I would guess.

A major concern for me is that I don't want disabled code to ship with  
a product, whether it will be executed or not doesn't matter. The code  
must not be present in the image. Currently I use a special image  
stripping that nukes methods tagged with a certain pragma. This  
however only works at the method level.

André


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

A not too hackish approach would be to use special comments
that could be modified by a precompile phase to uncomment
the portion that is to be active.

You could further mark the methods needing precompiling with
a pragma so you would not have to scan all your methods.

Terry
 
===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Dear Boris and Andre,
    you may need a | ``@temps | at the start to avoid failing to match
those RBSequenceNodes that have temps;  otherwise, just as Boris says.

Preserving comment positions and formatting is a tricky problem, not
everywhere solved in the rewriter.  If Andre takes this route then,
depending on the exact rewriting to be done, it may be desirable to
format methods that will be rewritten in a way that the formatter (or
the RBConfigurableFormatter) agrees with, and/or to keep any comments in
such methods to the start of the method or other simple positioning.

          Yours faithfully
             Niall Ross

         


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

I thought about that as well, but given that this step would only run for deployment purposes I didn't think formatting mattered.

-Boris (via BlackBerry)

----- Original Message -----
From: Niall Ross <[hidden email]>
To: Boris Popov
Cc: [hidden email] <[hidden email]>; VW NC <[hidden email]>
Sent: Tue Aug 18 08:37:37 2009
Subject: Re: [vwnc] Conditional Sourcecode - Please

Dear Boris and Andre,
    you may need a | ``@temps | at the start to avoid failing to match
those RBSequenceNodes that have temps;  otherwise, just as Boris says.

Preserving comment positions and formatting is a tricky problem, not
everywhere solved in the rewriter.  If Andre takes this route then,
depending on the exact rewriting to be done, it may be desirable to
format methods that will be rewritten in a way that the formatter (or
the RBConfigurableFormatter) agrees with, and/or to keep any comments in
such methods to the start of the method or other simple positioning.

          Yours faithfully
             Niall Ross

        

>My rewrite skillz might be a bit rusty, but something like the following should do the trick,
>
>Search for:
>       ``@.stmts1.
>       [``@.stmts2] log: `#literal.
>       ``@.stmts3.
>
>Replace with:
>       ``@.stmts1.
>       ``@.stmts3.
>
>Cheers,
>
>-Boris
>
> 
>

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc