WIBNI…

 

    1. A “Debugging Eliza” idea from BOBHYTAPb

      Here is a bomb of an idea: A Debugging Eliza.

      After a long and fruitless session of debugging a programmer reaches a certain dead end, where he has already glossed over the problem, has not found it, but noted subconsciously that that venue has been checked – or simply didn’t think about it. At this point he needs to talk to someone about this problem – a sort of a psychiatrist, which doesn’t even have to be human – it could be a slightly tweaked version of Eliza.

      “What are you doing?”

      “I am debugging Blah-Blah Industrial Application.”

      “What was the last thing you tried?”

      “I checked that the configuration file corresponds to the Blah-Blah…”

      “And how is the Blah-Blah?”

      “It’s perfectly fine.”

      “And how does that make you feel?”

      “It means the problem is somewhere else.”

      “Where else could it be?”

      etc.

      Obviously, this is where a lot of problems are found — when you are asking someone for help, and in the process of explaining the problem realize your error.

  • Eclipse, for all its cool pluggable architecture, lacks a basic thing — macros, which should be easy given the above. That is, a way to record (or write by hand, fine) a series of steps to instruct the Eclipse workbench to do something, and then play it back. Where’s AppleScript  when you need it?

    For example, instead of creating a walkthrough. Yes, part of the pain in this particular case can be solved by, for example, checking in dot-files into the source control, and then telling everyone to “Import existing projects into a workspace” after checking out the tree. But I can’t do that — there are dot-files of a “competing” approach checked into the repository, which suit some of us fine, but lack the things others want. but that’s in this particular example, and I cannot come up with another case right now, but trust me, they exist.

     

 

YODL

Once upon a time, BOBHYTAPb, Shmumer, others and yours truly thought
that a short-term LARP-like online game
could be interesting. (Nothing came of it, of course.) One of the
problems sited at the time was that computer games were lacking in
modeling of reality in general (duh!). In particular, the thought
went, the problem is with OOP itself. So YODL was conceived. (Did I
mention that nothing came out of it?) Shortly thereafter I discovered
Subject-Oriented
Programming
articles… A while later, I found notes about YODL
which I reproduce here in their incoherent entirety without any hopes
that anyone cares
, using this LJ as my personal repository of
stuff to refer to, maybe…


interface to other language/objects/functions?

1. Interceptable actions

The most limiting feature of this scheme is the finality of all
actions. In MUDs, one active object can intercept another object’s
action and veto it. Here, once an action is initiated it is performed
(see the caveat below). Other object can only react to it later
on. Example: in a MUD, you can place a closed chest and a guardian
over it. If you try to open the chest, the guardian stops you – have
to kill him first. In this scheme, if you are close enough to the
chest to open it – you open it, guardian or not.

2. Environment as a priviledged interceptor

Broadcasting messages to those that are interested and are eligible
cf 1?

3. yodl abstract

YODL is a mark-up language used to rapidly create new game worlds by placing objects in them.
Objects can be existing, taken from the library, as well as newly created (with the YODL as well!)
on the basis of other objects. YODL supports inheritance, with every object inheriting its properties
at least from some ideal object(s) (instances of which cannot be created) , or from other functional
objects. As is standard for such inheritances, properties can be overriden, added, erased.

An object can be created by inheriting from two objects – thus compound objects (e..g, a rifle with
laser targeting can be created out of stock rifle and stock laser pointer).

As much as it seems like a use of standard OO (object-oriented) approach, YODL presents important
innovation over traditional OO approach:

We strive to make the worlds we create believable. To do that, ideally,the user must be able to do
with a given object what he can do to it in the real world. That is impossible under standard OO paradigm.

In the OO paradigm, the designer must specify the behavior that each object is capable of. If a certain behaviour is not specified, the object cannot perform it. This is a great disadvantage. It is impossible to think of all the things it is possible to do with, for example, a cup. What if a user would like to try to hammer nails with it?

YODL provides for that and other behavior by NOT providing specifically for a behavior in an
object. Instead, YODL allows designers to specify a set of actions generally available (hitting, throwing,
heating up an object~) Then the object acted upon executes that action upon itself, and the action,
based on the object’s properties, decides on the consequences. For example, consider a metal cup and
ceramic one. The designer did not specify if either cup can be hit. However, an action of being hit
is in the system, and if a cup is hit, based on its properties, the action will decide if the cup breaks
(ceramic) or bends (metal).

In contrast to OO, this can be termed AO – action-oriented paradigm.
This is a misnomer, however, since YODL does not give preference to
actions (verbs) in favor of objects (nouns). Not getting into
linguistic debates, if we need both to better describe our world,
we will have both.

Other concepts introduced in YODL are related. To go into details, we need to
provide full YODL specification, which we can’t right now. Of interest immediately, however,
are also the following concepts.

  • Action inheritance – to ease the work of designers, actions can be inherited just as objects can be.
  • Faces – actions that can be inflicted upon the object can be
    calculated automatically, some being discarded (e.g., if an action of
    -Y´break¡ cannot possibly be inflicted upon an object, it is
    discarded).

Remaining actions represent a ´face¡ of an object. This is useful to the user, who can then be presented with a list of actions he can do upon the object, as a menu. More importantly, however, this can provide differentiating ´cognitive portraits¡ of user’s characters, forcing the character to see an object in some way. For example, a character that has never heard of a gun will be able to ´press the trigger¡ but not to ´shoot¡ the gun – and definitely not to load it.

Context-aware programming, in that respect like AOP.

An ACTOR is a performer of actions. An OBJECT is something the actions are performed on.

An OBJECT IMPLEMENTS a collection of INTERFACES.

An INTERFACE REQUIRES PROPERTY REFERENCES. When implementing the INTERFACE, the OBJECT must PROVIDE those to the INTERFACE. If the PROPERTY is not set by the OBJECT, it may be deemed UNKNOWN. The INTERFACE must specifically allow a PROPERTY to have an unknown state.

Properties have a state of Unknown. If an Object’s Interface Requires a PR for the Object, and the state of the Property is currently Unknown, the Object never returns that interface as a member of the Face. (or what of optional)

A subset of a collection of INTERFACES that an OBJECT implements is a FACE of the OBJECT. An OBJECT thus has many FACES. (-L~~~~~~~~?) (set of methods???)

When the ACTOR interacts with the OBJECT, the ACTOR constructs an INSTANCE of his PERCEPTION INTERFACE (parameterized both by LOCAL_ENVIRONMEN) and passes it to the OBJECT. Based on the received INSTANCE of the PERCEPTION interface, the OBJECT returns to the Actor a Face, that is, a subset of its collection of Interfaces. What the Actor sees then is a particular Face of the Object, parameterized by the current Actor’s Perception and the current state of Local_Environment.

(Addendum: The Object doesn’t choose shit. It just passes the PERCEPTION to the Intertfaces, and they decide which Subinterfaces make up the face).

TRIGGERS

A Role is a collection of Interfaces (CF. Role theory – GG2001).

Multiple Inheritance Resolution: User Intervention. If an Actor invokes a Method appearing in more than one Interface, the Actor is asked to specify which Interface he had in mind. Or, the desiner provides a default order?

Deconstruction Interface:

BASIC Interface

A tool for script creation — just record the proceedings

Environment Triggers — implicit, e.g., an air balloon’s trigger on local pressure.

PROPERTIES — not just numbers, but instead objects with access methods!

Properties implying interfaces requiring them? — Properties only imply Passive; ACTIVE require knowledge and must be explicitly declared.

Every Interface comes of two Complementary types — Active and Passive. Pasive interface contains handlers for the Active interface.

The Actor passes the collection of his Active interfaces to the Object (with the Perception module). The Object returns a Collection of the Actors subinterfaces, corresponding to what the Object can handle given the current state of Environment and of the Actor. This could inolve Fallback on some of the active interfaces of the actor to their ancestors, as best as the object can handle for that particular interface.

Environment and Actor are special cases of Objects. The also provide Faces to the Actor. Actor’s Face includes Inventory, for example.

Case Study: Actor contains Active “Run” and Passive “Run”. P-RUN changes actors coordinates.

Waht goes into Environment? Walls treated as Objects? Is Environment any different from a specialized collection of Objects we don’t want to ttreat as Objects? Philosophically?

A Face includes all the Representation stuff — graphics, audio, smells, whatever. In fact, these should depend upon the Actor’s Perception and not on ly on the state of the Object.

PH: An Interface can be separated into Effect and Implementation.

Flying is an effect. Winged Flying, Propeller Flying, Jet Flying – implementations of that effect. This mimics Templates — but not completely.

Properties imply Passive intefaces — Passive Interfaces are written using fixed property names. Ergo, Interface designers must communicate heavily.


 Keyword unknown 
 Actions {
 
 Hit (subject object) where 
 
 Object has , is
 
 Subject has 
 
 {
 
 
 
 }
 
 } 
 
 
 Actor me {
 
 Knows hit 
 
 } 
 
 
 class chair implements matter {
 
 state = solid;
 
 // weight not here - automatically unknown
 
 } 
 
 
 class Neanderthal knows wood {
 
 } 
 
 
 class Bird knows wood 
 
 
 interface matter{
 
 property state : {solid, liquid, gas};
 
 optional property weight;
 
 } 
 
 
 interface wood implements matter {
 
 property hardness : 3;
 
 } 
 
 
 class blade implements iron {
 
 property edge: .1; 
 
 
 cut (matter m) {
 
 if (m.state=solid) {
 
 if ()~ 
 
 
 }
 
 } 
 
 
 Neanderthal N; 
 
 
 Bird b; 
 
 
 Wood w;
 
 Knife k;
 
 b.use(k.cut(w)); 
 
 

Some random links jotted in these notes:

RSS WIBNI

So, I broke down and got a paid account just so I could
syndicate (oh, and ).
Does this even work? We’ll see…

So, while I am at it, here’s an RSS WIBNI: a weighted RSS. So that,
for example, occassional entries from stay
on top, rather than being beaten by frequent spewage from something
like /. (I won’t even link to that den of iniquity, but I read
it for the articles…)

Rant

The debate holy war on the topic of software engineering vs “real” engineering seems as endless as GWOT. I am too lazy to do an extensive
search, but I do remember one of the pithy definitions to claim the use of differential equations as a necessary condition…

DISCLAIMER/DIGRESSION
I don’t really care, but “engineer” does sound cooler than “programmer”, which doesn’t have a sci-fi ring to it anymore, or “developer”, ’cause Donald Trump is also one — not that he isn’t cool

But I thought I’d throw just one more difference into the mix. Software engineers — at least those that work in application development — have to use knowledge of other domains — those, for which software is written (e.g., finance, etc.)

As far as I am concerned, these domains tend to be boring… I like technology for technology’s sake… Does that make me more of an engineer?

Discuss

I wonder whether Michael Swaine weighed/will weigh in on it…

P.S. Please…

configureWebserverDefinition.jacl

Per Web
server plug-in installation doc (step 19)
, we should copy the
configureweb_server_name.bat script, generated by
the plugin installer, to the WAS_HOME/bin directory and run it
in order to map the installed applications to the Web server. This was giving us problems on Windows 2003, such as this:

Configuration save is not complete, exception = com.ibm.ws.scripting.ScriptingException:
com.ibm.websphere.management.exception.ConfigServiceException:
WKSP0008E RepositoryException while checking the state of
cells/mycell/applications/application.ear/deployments/application/foo.jar/META-INF/ibm-ejb-jar-ext.xmi
in the master repository -com.ibm.ws.sm.workspace.WorkSpaceException:
WKSP0016E Error get digest for cells/mycell/applications/application.ear/deployments/application/foo.jar/META-INF/ibm-ejb-jar-ext.xmi.workspace_save – java.io.IOException: The system cannot find the specified file, either the filename is too long on Windows system or run out of file descriptor on UNIX platform. java.io.FileNotFoundException: D:optWebSphereAppServerprofilesAppSrv01wstempScript10afa2477bfworkspacecellsmycellapplicationsapplication.eardeploymentsapplicationfoo.jarMETA-INFibm-ejb-jar-ext.xmi.workspace_save (The handle is invalid.)

WASX7309W: No “save” was performed before the script “D:optWebSphereAppServerbinconfigureWebserverDefinition.jacl” exited; configuration changes will not be saved.

What is happening is twofold.

First, the
configureWebserverDefinition.jacl does a save only at the end, which fails for all installed applications. To narrow the problem down, I put $AdminConfig reset after foreach Application $ApplicationList {, and moved the

 if {[catch {$AdminConfig save} result]} {
 puts "Configuration save is not complete, exception = $result"
 } else {
 puts "Configuration save is complete."
 }
 

block from the end of the script into the else clause of

 if {[catch {$AdminApp edit $Application [subst {-MapModulesToServers {$targetMapList } } ]} result]} {
 puts "Target mapping is not updated for the application $Application, exception = $result"
 } else {
 puts "Target mapping is updated for the application $Application"
 ...
 

I think saving this per-application is better, at least for narrowing the problematic apps down, but I suppose it’s a matter of preference…

Now we see that all applications except for two are being updated. Without digging into what exactly is special about those two, it’s enough to go to the “Map modules to servers” in WAS console for any other app to see that the JACL script mapped all modules to the web server – including the EJB modules. Not only is that silly and useless, but also is causing “the filename is too long” thing. So we add another condition into the configureWebserverDefinition.jacl to only map Web modules to the web server, by
changing the block where we set targetMapList as follows:

 #--------------------------------------------------------------
 # Check if web server is already defined as the target
 #--------------------------------------------------------------
 set index [string first $newTarget $currentTargets]
 
 set targetMapList "$targetMapList { {$moduleName} $moduleUri $currentTargets }"
 if {($index < 0) } {
 set isWebModule [string first ".war,WEB-INF/web.xml" $moduleUri]
 if {( $isWebModule < 0)} {
 puts "$moduleUri is not a Web module, skipping..."
 } else { 
 puts "Will map $moduleUri to $newTarget"
 set targetMapList "$targetMapList { {$moduleName} $moduleUri $currentTargets+$newTarget }" 
 }
 }
 

The configureWebserverDefinition.jacl modified as above is at
Misc
module of jSewer project on SourceForge
.