Jump to content











Photo
* * * * * 1 votes

BuildModel and temporary files..


  • Please log in to reply
29 replies to this topic

#26 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10557 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 08 July 2007 - 07:21 PM

First of all - I think you are a brilliant coder!

But unfortunately this script still seems a bit "complicated" solution for several reasons..

- implies people to already know how it is used and where it can be found (this is very complicated most times)
- finding a script is difficult since they'd have to know the filename and path location (also takes time to browse folders and find the right script)
- implies people to repeat the same steps over and over again when they want to run more than one script.
- what if want to run virtual PC 2007, vmware or the script to copy everything to USB? having a script trying to guess all possible options is still making people having to keep the script often updated. More work, less eficiency or flexibility = less probabilities to survive longer.

It's not the script (which seems very well coded based on your past work) - it's the build model itself that keeps all scripts tied to build from scratch method.

This script would also add an additional extra tool instead of letting build model grow to more advanced techniques - this was a good feature on the old standard project for often repeated testings, one of the reasons why I had so much fun tweaking and eventually left bartpe. It's really too bad that we don't have it here on nativeEx.. :thumbup:


Just something simple - run script, create ISO (or do any other prefered action). :1st:


Don't mean to seem ungrateful for your displayed work, just my honest opinion. :thumbup:

#27 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 08 July 2007 - 08:06 PM

First of all - I think you are a brilliant coder!

Thanks :1st: . But I think we still speak about two different things.

I understood your previous posts that a script developer should have the possibility to test his new script.
And this is solved by the new script:
  • The developer once stores his/her predefined test project. My recommandation is 'minimum_internet'
    After that 'forget' the definition, just use it!
  • When he/she anywhen wants to test a new script, there are two possibilities:
    • Copy into CodeBox
    • Define the path to the script (as a developer you surely know name and path)
  • In the scrollboxes define
    • UPX
      • Yes
      • No
    • ISO type
      • Standard
      • BootSDI
    • Emulator
      • None (if you only want to burn a CD)
      • qEmu
      • VirtualBox
      • VirtualPC
      • VMWare
      • ... (currently no more options)
        They are automatically added, if there is a script.
    • Burn CD
      • Yes
      • No
  • Click 'Build Test' and you come into your favorite emulator or burn the CD.
    There is no 'run project', just using the complete %Target% and add something before building the ISO
What's complicated?
What's redundant or unnecessary?
Which method is faster to test a single script?

BTW: buildModel cannot handle this. buildModel is only building the 'documents and settings' of the final ISO.
The build made at compile time causes that at boot time this can be skipped which in large ISOs saves a lot of time.

Peter

- implies people to already know how it is used and where it can be found (this is very complicated most times)

This script is a tool and a .script developer has no troubles to find it at 'Tools'

- implies people to already know how it is used and where it can be found (this is very complicated most times)

When I use a new tool, I at least (and usually only) once have to read something, maybe after clicking the 'Help' button.

- implies people to repeat the same steps over and over again when they want to run more than one script.

The script is named 'SingleTest'.
If somebody wants to test a bunch of new scripts, I gave him/her already a good tool: ReOpen.Script

- what if want to run virtual PC 2007, vmware or the script to copy everything to USB? having a script trying to guess all possible options is still making people having to keep the script often updated. More work, less eficiency or flexibility = less probabilities to survive longer.

Virtual PC, VMWare etc. are no problem (see above).
... often updated ... I'm starting to think about this. My current solution is for 'quick&dirty checks'.

Don't mean to seem ungrateful for your displayed work, just my honest opinion. yammer.gif

I do not have the feeling to be affronted or similar.
I know that we and all other members of the forum want to have the best solutions.
And to reach this goal, the discussions sometimes have to be confrontating.

Peter

#28 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 08 July 2007 - 08:29 PM

... often updated ... I'm starting to think about this. My current solution is for 'quick&dirty checks'.


When thinking about this, a new 'crazy idea'.

I have the following hallucination:
There is an IDE like WinBuilder program
  • 'Compiling' several scripts to 'object files'
  • 'Recompiling incremental' if something changed.
  • 'Linking' all valid script 'object files' to a final ISO
???

Peter

#29 Nuno Brito

Nuno Brito

    Platinum Member

  • .script developer
  • 10557 posts
  • Location:boot.wim
  • Interests:I'm just a quiet simple person with a very quiet simple life living one day at a time..
  •  
    European Union

Posted 08 July 2007 - 08:37 PM

I give up on more ideas.. :1st:

Surely agree with all your points, but we still get a buildmodel that could work better - a build method completely independent from having to run the project from the top to the bottom several times, why should we need to use a tool when this could come by default?

nativeEx scripts will still confuse people to run them in single mode because they are not meant to be used this way - wouldn't it be more intuitive and a better improvement of the current buildmodel?

Not just for .script developers - but for everyone starting fresh and I think this would be a good improvement.. :thumbup:


My wife also says that I can get very persistent whenever I'm locked to an idea (which can effectively annoy other people after a while). I know this should give too much work on your side to implement - I just wish we could indeed give a good use to the run single script feature inside each script interface and make things more fluid.

---------------------------------------------

About using objects - isn't wb an IDE by itself in a certain way? You add up scripts as objects which are categorized and can have several properties built-in and run them by specific order just like compiling to a final binary result?

:thumbup:

#30 pscEx

pscEx

    Platinum Member

  • Team Reboot
  • 12707 posts
  • Location:Korschenbroich, Germany
  • Interests:What somebody else cannot do.
  •  
    European Union

Posted 08 July 2007 - 09:11 PM

Surely agree with all your points, but we still get a buildmodel that could work better - a build method completely independent from having to run the project from the top to the bottom several times, why should we need to use a tool when this could come by default?

buildModel does only and is designed only for 'compile time' creating shortcuts and rarely copy some files.
To extend buildModel to your intention is rather difficult, not to say impossible.

But back to my previous post: Why let an application (script) manage the incremental compile and link of the IDE (WinBuilder)?

Peter

EDIT: Before today discussing in a two person's party, let's make a break. Other members may read this and give their opinion.

Edited by psc, 08 July 2007 - 09:15 PM.
Additional info





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users