Loading ...
Sorry, an error occurred while loading the content.

Re: VMCrash - Access Violation

Expand Messages
  • davegriswold9
    Hi Paul, Until yesterday, it was not even possible to work on the Strongtalk VM because the sources were not available. So there is no process for submitting
    Message 1 of 30 , Sep 12, 2006
    View Source
    • 0 Attachment
      Hi Paul,

      Until yesterday, it was not even possible to work on the Strongtalk VM
      because the sources were not available. So there is no process for
      submitting bugs because there has been no development effort.

      Obviously, with the release of the source code, that can now change,
      if enough people with the right talents decide to get involved. All
      the members of the original Strongtalk team are off doing other
      things, but a number of us are willing to be involved to some extent
      in the open source development of Strongtalk, since we are in the
      position to know that the technology really does work great, and
      ultimately we are the only ones who can answer questions about it
      right now.

      So hold that thought- we are going to see who is interested in helping
      out. We don't yet know what direction development might take. It
      might be development of Strongtalk as Strongtalk, it might be adapting
      the VM to something like Squeak, or it might be using the VM
      technology for other languages.

      If enough people with the right talents step forward and want to work
      on Strongtalk as an independent project from other Smalltalks, then
      there will be plenty to do, both for VM hackers inside the VM, and
      also at the Smalltalk/Strongtalk level. I'll note your name, and over
      the next few weeks we'll see whether it is worth setting up a separate
      development forum for Strongtalk.

      As for questions and answers: what particular questions do you think
      people would want answered that aren't being answered? I would be
      more than happy to put more Q&A on the web site if you can be more
      specific.

      Cheers,
      Dave

      --- In strongtalk@yahoogroups.com, "beckfordp" <beckfordp@...> wrote:
      > [...]
      >
      > Hi Gilad,
      >
      > Is there a process for submitting bug fixes? Is anyone in the process
      > of setting up an open source project? I would love to help. Not sure
      > if my skill set is appropriate though (I've got a lot of general
      > experience, but I've never done any VM hacking).
      >
      > The anouncement leaves more questions then answers. If you can answer
      > the obvious questions people are likely to have that would be great.
      >
      > Paul.
      >
    • Gilad Bracha
      Hi Paul, I guess Dave answered most of your questions. I agree that there are more questions than answers right now. The main thing for me has been to get
      Message 2 of 30 , Sep 12, 2006
      View Source
      • 0 Attachment
        Hi Paul,

        I guess Dave answered most of your questions.  I agree that there are more questions than answers right now.
        The main thing for me has been to get this out into the world in an unrestrictive way. 

        There are lots of directions one could take this. I think the most important one is to get the code so it builds properly on modern tools. It doesn't right now for a variety of reasons that still need to be fully understood. Obviously, C++ has changed a lot in the last decade. I've made most of the changes necessary, and have a version that builds - but it fails to run :-(. We're investigating why that is the case. I hope we can solve it quickly, but it may be non-trivial.  The leading theory is that the C++ compiler's calling conventions may have changed, which causes problems in the transition from assembly code back to C++.

        Solving the issues above puts one in a position to work on stability so that problems like the one you reported do not occur. I think these two points need to be addressed for the system to go anywhere. I'm trying to get resources to help with this at Sun, but I cannot make any promises yet. 

        I'm also very interested in getting ports to MacOS and Linux. You can already run Strongtalk on those systems thanks to Wine. I myself have run it on my macintel using Crossover (which is basically Wine), and I'm told it works for Linux as well. However, one wants a real port.

        Most of these tasks are VM specific. Once they are accomplished, there are, as Dave said, many different directions people could go in.

        I find the possibility of a portable, high performance client with native look and feel very exciting. In that respect, I'd be most interested to see work on Strongtalk as a whole system rather than just an engine for other Smalltalk's. That said, everyone is free to take this in the direction that suits them.  The possibilities are definitely NOT mutually exclusive.

        So please bear with us and let's see what kindof model can be worked out for moving this forward.




        On Sep 12, 2006, at 5:23 AM, beckfordp wrote:


        Hi Gilad,

        Is there a process for submitting bug fixes? Is anyone in the process
        of setting up an open source project? I would love to help. Not sure
        if my skill set is appropriate though (I've got a lot of general
        experience, but I've never done any VM hacking).

        The anouncement leaves more questions then answers. If you can answer
        the obvious questions people are likely to have that would be great.

        Paul.


      • Todd Blanchard
        Hi Gilad, I m really pleased to see this come out. I hope you have the time to lend some support. If I were going to turn this into a killer platform I think
        Message 3 of 30 , Sep 12, 2006
        View Source
        • 0 Attachment
          Hi Gilad,

          I'm really pleased to see this come out.  I hope you have the time to lend some support.

          If I were going to turn this into a killer platform I think I would:

          1) Ditch the Windows UI in favor of  wxWidgets.  (http://www.wxwidgets.org) This will get us a nice portable package with native looking GUIs.  Quite a few people are using the wx stuff with great success.  For instance, the Outlook-killer known as Chandler is written in Python with bindings to wxWidgets.

          2) I'm quite fond of Squeak's codebase - lots of really great stuff and Craig Latta has developed what amounts to a Smalltalk bootstrapping kit he calls Spoon.  Craig can "imprint" a really minimal image with additional code from a mother image by "faulting" methods on demand over a socket.  http://www.netjam.org/spoon/

          I think embracing these enabling technologies could really help bootstrap development.

          -Todd Blanchard


          On Sep 12, 2006, at 8:10 PM, Gilad Bracha wrote:

          Hi Paul,


          I guess Dave answered most of your questions.  I agree that there are more questions than answers right now.
          The main thing for me has been to get this out into the world in an unrestrictive way. 

          There are lots of directions one could take this. I think the most important one is to get the code so it builds properly on modern tools. It doesn't right now for a variety of reasons that still need to be fully understood. Obviously, C++ has changed a lot in the last decade. I've made most of the changes necessary, and have a version that builds - but it fails to run :-(. We're investigating why that is the case. I hope we can solve it quickly, but it may be non-trivial.  The leading theory is that the C++ compiler's calling conventions may have changed, which causes problems in the transition from assembly code back to C++.

          Solving the issues above puts one in a position to work on stability so that problems like the one you reported do not occur. I think these two points need to be addressed for the system to go anywhere. I'm trying to get resources to help with this at Sun, but I cannot make any promises yet. 

          I'm also very interested in getting ports to MacOS and Linux. You can already run Strongtalk on those systems thanks to Wine. I myself have run it on my macintel using Crossover (which is basically Wine), and I'm told it works for Linux as well. However, one wants a real port.

          Most of these tasks are VM specific. Once they are accomplished, there are, as Dave said, many different directions people could go in.

          I find the possibility of a portable, high performance client with native look and feel very exciting. In that respect, I'd be most interested to see work on Strongtalk as a whole system rather than just an engine for other Smalltalk's. That said, everyone is free to take this in the direction that suits them.  The possibilities are definitely NOT mutually exclusive.

          So please bear with us and let's see what kindof model can be worked out for moving this forward.




          On Sep 12, 2006, at 5:23 AM, beckfordp wrote:


          Hi Gilad,

          Is there a process for submitting bug fixes? Is anyone in the process
          of setting up an open source project? I would love to help. Not sure
          if my skill set is appropriate though (I've got a lot of general
          experience, but I've never done any VM hacking).

          The anouncement leaves more questions then answers. If you can answer
          the obvious questions people are likely to have that would be great.

          Paul.




        • Gilad Bracha
          Todd, ... Thanks for the pointer. I was not aware of this package. It seems to have the same goal - a portable yet native API. This is really Dave s ballpark,
          Message 4 of 30 , Sep 12, 2006
          View Source
          • 0 Attachment
            Todd,


            On Sep 12, 2006, at 8:31 PM, Todd Blanchard wrote:


            1) Ditch the Windows UI in favor of  wxWidgets.  (http://www.wxwidgets.org) This will get us a nice portable package with native looking GUIs.  Quite a few people are using the wx stuff with great success.  For instance, the Outlook-killer known as Chandler is written in Python with bindings to wxWidgets.







            Thanks for the pointer. I was not aware of this package. It seems to have the same goal - a portable yet native API.  This is really Dave's ballpark, but I'll say a few words anyway. The Strongtalk GUI was designed so that the Windows bindings are localized, and most code does not depend on it. So, in principle, one should be able to get it to work on top of alternate native GUIs.  However, in practice only the Windows binding exists. Proof in the pudding etc.

            Tthe advantage of using another framework is that you don't need to do the GUI port multiple times etc., the framework is mature etc. The downside is being tied to a bunch of extra C++ libraries, and the possible effects on startup time, process footprint etc. One would have to evaluate this very carefully. 




            2) I'm quite fond of Squeak's codebase - lots of really great stuff and Craig Latta has developed what amounts to a Smalltalk bootstrapping kit he calls Spoon.  Craig can "imprint" a really minimal image with additional code from a mother image by "faulting" methods on demand over a socket.  http://www.netjam.org/spoon/







            This sounds like a useful thing. I'll take a look.


            Thanks for both suggestions. Keep them coming.


            Cheers,

            Gilad


          • davegriswold9
            Hi Todd, Good Suggestions. ... The Strongtalk UI isn t the Windows UI. There is a Windows binding right now, but there s not a single line of platform
            Message 5 of 30 , Sep 12, 2006
            View Source
            • 0 Attachment
              Hi Todd,

              Good Suggestions.

              > 1) Ditch the Windows UI in favor of wxWidgets. (http://
              > www.wxwidgets.org) This will get us a nice portable package with
              > native looking GUIs. Quite a few people are using the wx stuff with
              > great success. For instance, the Outlook-killer known as Chandler is
              > written in Python with bindings to wxWidgets.

              The Strongtalk UI isn't the Windows UI. There is a Windows binding
              right now, but there's not a single line of platform dependent UI code
              outside of a few classes. The idea was to have pure Smalltalk
              widgets, but with enough machinery so that widgets that wanted to map
              to a native widget could coexist, and nest in any way, and be subject
              to the same layout mechanism and event handling mechanism and
              rendering mechanism, etc. so that it feels like a unified whole, and
              not a frankenstein's monster of disparate widgets.

              From a quick glance, I really like the idea of wxWidgets. In fact, it
              might fit perfectly with Strongtalk's UI design, as long as their
              concepts aren't too alien. The whole setup of the strongtalk UI is to
              provide a framework to patch native widgets into the mechanisms above.
              I don't think it would be insanely hard. Strongtalk uses only a
              minimal set of host features.

              > 2) I'm quite fond of Squeak's codebase - lots of really great stuff
              > and Craig Latta has developed what amounts to a Smalltalk
              > bootstrapping kit he calls Spoon. Craig can "imprint" a really
              > minimal image with additional code from a mother image by "faulting"
              > methods on demand over a socket. http://www.netjam.org/spoon/

              I like Squeak too, it's what I use day-to-day! I like Strongtalk's
              design better, naturally :0, but Strongtalk doesn't have a real
              debugger yet, and until now if the VM broke I was broke. Anyway, I
              hope there is lots of transferrence both ways with Squeak.

              > If I were going to turn this into a killer platform I think I would:

              Are you?
              -Dave
            • Todd Blanchard
              ... I m not what you d call a VM level engineer (although I reckon I m a lot better at C++ than most) - I m more of a gifted glue gunner/ systems engineer
              Message 6 of 30 , Sep 13, 2006
              View Source
              • 0 Attachment
                On Sep 12, 2006, at 10:31 PM, davegriswold9 wrote:
                >> If I were going to turn this into a killer platform I think I would:
                > Are you?
                I'm not what you'd call a VM level engineer (although I reckon I'm a
                lot better at C++ than most) - I'm more of a gifted glue gunner/
                systems engineer type. I spot synergies and stick stuff together to
                make new things.

                An example is http://www.objectiveclips.com which is a marriage of
                NASA's CLIPS inference engine with the Objective C language and the
                FScript interpreter. Its really quite powerful and provides a novel
                way to build intelligent applications using Apple Cocoa GUI with
                their CoreData persistence mechanism - and then you write rules to
                animate the objects. Way cool - but at the end of the day my big
                ideas are glue.

                I've also contributed to an Objective C bridge for Squeak. More glue.

                And I wrote an adaptor that lets GLORP work off of Apple WebObjects
                EOF models. Yet more glue.

                So that's my talent and gift to the world - glue.

                I'd be willing to help clean up/modernize the C++ source and get it
                compiling with good old gcc, but for the next month I have 2 jobs
                already (one is a little consulting business with Seaside on Squeak -
                the other is a program management job at Big River Books in Seattle -
                that one is going away in a month). Also I only work on Macs.
                There's not a Windows machine in the house.

                Really, I think the best thing that could happen would be for the
                Squeak community to adopt it thing.

                Dan Ingalls wrote a nice note on the squeak list alerting us to the
                release about a half day before your note appeared. There is a list
                specifically for Squeak VM discussions:

                vm-dev@...

                where the VM maintainers hang out. My one contribution there is
                probably that I got the first of the Intel Mac builds working and
                made it available to others.

                -Todd Blanchard
              • pahihu
                ... need ... last ... transition ... Hi, I have changed the sources to compile under VS6 and VS7.1. The main problem was with the friend function declarations
                Message 7 of 30 , Sep 13, 2006
                View Source
                • 0 Attachment
                  --- In strongtalk@yahoogroups.com, Gilad Bracha <gilad@...> wrote:
                  > There are lots of directions one could take this. I think the most
                  > important one is to get the code so it builds properly on modern
                  > tools. It doesn't right now for a variety of reasons that still
                  need
                  > to be fully understood. Obviously, C++ has changed a lot in the
                  last
                  > decade. I've made most of the changes necessary, and have a version
                  > that builds - but it fails to run :-(. We're investigating why that
                  > is the case. I hope we can solve it quickly, but it may be non-
                  > trivial. The leading theory is that the C++ compiler's calling
                  > conventions may have changed, which causes problems in the
                  transition
                  > from assembly code back to C++.

                  Hi,

                  I have changed the sources to compile under VS6 and VS7.1. The main
                  problem was with the friend function declarations and definitions
                  embedded inside the class declarations. That solved easily.

                  The debug VM works flawlessly under VS6. The product VM has some
                  tweaks under VS6 and VS7.1 with the optimization options: do not
                  enable global optimizations at all (/Og). The other options
                  could be turned on (/Oityb1 /Gs /Gf /Gy).

                  The linker is not able to convert the TASM produced OMF files
                  under VS7.1 (under VS6 it is ok). So I have used the ones found
                  in the directory asm_objs/coff.

                  The VS6 version runs all the Slopstone and Smopstone benchmarks,
                  but the VS7.1 version got an exception in the Smopstone benchmark
                  'accessing strings'.

                  That's all.

                  Regards,
                  Andras Pahi
                • beckfordp
                  ... Hi Dave, You ve answered all the questions I had. I guess we need to watch and see how things develop. BTW. Congratulations on getting the thing out there.
                  Message 8 of 30 , Sep 13, 2006
                  View Source
                  • 0 Attachment
                    --- In strongtalk@yahoogroups.com, davegriswold9 <no_reply@...> wrote:
                    Hi Dave,

                    You've answered all the questions I had. I guess we need to watch and
                    see how things develop.

                    BTW. Congratulations on getting the thing out there. It is an
                    impressive piece of work!

                    Paul.
                    >
                    > Hi Paul,
                    >
                    > Until yesterday, it was not even possible to work on the Strongtalk VM
                    > because the sources were not available. So there is no process for
                    > submitting bugs because there has been no development effort.
                    >
                    > Obviously, with the release of the source code, that can now change,
                    > if enough people with the right talents decide to get involved. All
                    > the members of the original Strongtalk team are off doing other
                    > things, but a number of us are willing to be involved to some extent
                    > in the open source development of Strongtalk, since we are in the
                    > position to know that the technology really does work great, and
                    > ultimately we are the only ones who can answer questions about it
                    > right now.
                    >
                    > So hold that thought- we are going to see who is interested in helping
                    > out. We don't yet know what direction development might take. It
                    > might be development of Strongtalk as Strongtalk, it might be adapting
                    > the VM to something like Squeak, or it might be using the VM
                    > technology for other languages.
                    >
                    > If enough people with the right talents step forward and want to work
                    > on Strongtalk as an independent project from other Smalltalks, then
                    > there will be plenty to do, both for VM hackers inside the VM, and
                    > also at the Smalltalk/Strongtalk level. I'll note your name, and over
                    > the next few weeks we'll see whether it is worth setting up a separate
                    > development forum for Strongtalk.
                    >
                    > As for questions and answers: what particular questions do you think
                    > people would want answered that aren't being answered? I would be
                    > more than happy to put more Q&A on the web site if you can be more
                    > specific.
                    >
                    > Cheers,
                    > Dave
                    >
                    > --- In strongtalk@yahoogroups.com, "beckfordp" <beckfordp@> wrote:
                    > > [...]
                    > >
                    > > Hi Gilad,
                    > >
                    > > Is there a process for submitting bug fixes? Is anyone in the process
                    > > of setting up an open source project? I would love to help. Not sure
                    > > if my skill set is appropriate though (I've got a lot of general
                    > > experience, but I've never done any VM hacking).
                    > >
                    > > The anouncement leaves more questions then answers. If you can answer
                    > > the obvious questions people are likely to have that would be great.
                    > >
                    > > Paul.
                    > >
                    >
                  • davegriswold9
                    That s great Andras, now we can get the binary and source release synced. You get a gold star for first community contribution- and just what we needed, too!
                    Message 9 of 30 , Sep 13, 2006
                    View Source
                    • 0 Attachment
                      That's great Andras, now we can get the binary and source release
                      synced. You get a gold star for first community contribution- and
                      just what we needed, too! ;-)
                      Thanks!
                      -Dave

                      --- In strongtalk@yahoogroups.com, "pahihu" <pahi@...> wrote:
                      > [..]
                      > Hi,
                      >
                      > I have changed the sources to compile under VS6 and VS7.1. The main
                      > problem was with the friend function declarations and definitions
                      > embedded inside the class declarations. That solved easily.
                      >
                      > The debug VM works flawlessly under VS6. The product VM has some
                      > tweaks under VS6 and VS7.1 with the optimization options: do not
                      > enable global optimizations at all (/Og). The other options
                      > could be turned on (/Oityb1 /Gs /Gf /Gy).
                      >
                      > The linker is not able to convert the TASM produced OMF files
                      > under VS7.1 (under VS6 it is ok). So I have used the ones found
                      > in the directory asm_objs/coff.
                      >
                      > The VS6 version runs all the Slopstone and Smopstone benchmarks,
                      > but the VS7.1 version got an exception in the Smopstone benchmark
                      > 'accessing strings'.
                      >
                      > That's all.
                      >
                      > Regards,
                      > Andras Pahi
                      >
                    • Krzysztof Kowalczyk
                      ... This sounds great. Could you make your sources available somewhere so that others can build on top of your work (instead of redoing it)? Thanks, -- kjk
                      Message 10 of 30 , Sep 13, 2006
                      View Source
                      • 0 Attachment
                        On 9/13/06, pahihu <pahi@...> wrote:
                        > I have changed the sources to compile under VS6 and VS7.1. The main
                        > problem was with the friend function declarations and definitions
                        > embedded inside the class declarations. That solved easily.
                        >
                        > The debug VM works flawlessly under VS6. The product VM has some
                        > tweaks under VS6 and VS7.1 with the optimization options: do not
                        > enable global optimizations at all (/Og). The other options
                        > could be turned on (/Oityb1 /Gs /Gf /Gy).
                        >
                        > The linker is not able to convert the TASM produced OMF files
                        > under VS7.1 (under VS6 it is ok). So I have used the ones found
                        > in the directory asm_objs/coff.
                        >
                        > The VS6 version runs all the Slopstone and Smopstone benchmarks,
                        > but the VS7.1 version got an exception in the Smopstone benchmark
                        > 'accessing strings'.

                        This sounds great. Could you make your sources available somewhere so
                        that others can build on top of your work (instead of redoing it)?

                        Thanks,

                        -- kjk
                      • pahihu
                        ... Hi, You could find the changes in the Files section (strongtalk-diff.zip). Please read the included readme.txt. Regards, Andras Pahi
                        Message 11 of 30 , Sep 13, 2006
                        View Source
                        • 0 Attachment
                          --- In strongtalk@yahoogroups.com, "Krzysztof Kowalczyk"
                          <kkowalczyk@...> wrote:
                          > This sounds great. Could you make your sources available somewhere so
                          > that others can build on top of your work (instead of redoing it)?
                          >
                          > Thanks,
                          >
                          > -- kjk
                          >

                          Hi,

                          You could find the changes in the Files section (strongtalk-diff.zip).
                          Please read the included readme.txt.

                          Regards,
                          Andras Pahi
                        • Todd Blanchard
                          A version control system, project admin, and set of trusted reviewers/committers is going to be required. ... This sounds great. Could you make your sources
                          Message 12 of 30 , Sep 13, 2006
                          View Source
                          • 0 Attachment

                            On 9/13/06, pahihu <pahi@info-m. hu> wrote:
                            > I have changed the sources to compile under VS6 and VS7.1. The main
                            > problem was with the friend function declarations and definitions
                            > embedded inside the class declarations. That solved easily.
                            >
                            > The debug VM works flawlessly under VS6. The product VM has some
                            > tweaks under VS6 and VS7.1 with the optimization options: do not
                            > enable global optimizations at all (/Og). The other options
                            > could be turned on (/Oityb1 /Gs /Gf /Gy).
                            >
                            > The linker is not able to convert the TASM produced OMF files
                            > under VS7.1 (under VS6 it is ok). So I have used the ones found
                            > in the directory asm_objs/coff.
                            >
                            > The VS6 version runs all the Slopstone and Smopstone benchmarks,
                            > but the VS7.1 version got an exception in the Smopstone benchmark
                            > 'accessing strings'.

                            This sounds great. Could you make your sources available somewhere so
                            that others can build on top of your work (instead of redoing it)?

                            Thanks,

                            -- kjk

                          • davegriswold9
                            ... Yes, indeed. This release came a bit faster than I expected, but I ll starting to try to figure this out. Not having dealt directly with open-source
                            Message 13 of 30 , Sep 13, 2006
                            View Source
                            • 0 Attachment
                              --- In strongtalk@yahoogroups.com, Todd Blanchard <tblanchard@...> wrote:
                              >
                              > A version control system, project admin, and set of trusted
                              > reviewers/committers is going to be required.

                              Yes, indeed. This release came a bit faster than I expected, but I'll
                              starting to try to figure this out. Not having dealt directly with
                              open-source development, I am open to advice on the right tools,
                              hosts, etc, if anyone knows a lot about that, so we can do things in
                              whatever the current standard way is. There is plenty of room here if
                              people want to help.

                              The biggest problem is that all the trusted reviewers are pretty busy.
                              I at least am definitely going to be spending some non-trivial amount
                              of time on this, however I need to do lots of boning up on the VM
                              before I would trust myself to review changes to the C++. Gilad I
                              think is in a pretty similar situation, although I think there is a
                              possibility he might be able to get some help together. Gilad and I
                              can deal with pretty much all the Strongtalk code.

                              The team members who are the real experts on the VM internals are
                              unfortunately very busy people, but there might be some hope for a
                              little attention from them. One thing I hope to do is to get some of
                              them to give talks on the VM internals, and capture them, so we can
                              start a little educational effort for those who wish to understand the VM.

                              Another reason I am not diving right in with this is that it is not
                              clear yet where the community interest is going to drive this thing,
                              or whether there are enough people with the right skills and time to
                              get this to critical mass. That's what we trying to assess right now.

                              And just as important, there may be several immediate forks if the VM
                              gets used for things other than straight development as Strongtalk.
                              If all the interest, for example, is in having Squeak adopt this VM,
                              then I would be inclined to focus more on that, since there is already
                              an active community working on the libraries. Smalltalk doesn't need
                              any more divisions than necessary, and I don't really want to sink any
                              effort into finishing and perfecting the Strongtalk libraries if no
                              one is going to use them. There's a ton of work to do in the
                              libraries and it has pretty much all been done before elsewhere.

                              But even if the VM is adopted by Squeak, we need at the least a stable
                              minimal baseline Strongtalk that is reliable, usable, and ported to
                              Linux and Mac, but without any big feature changes compared to now,
                              other than maybe a debugger, although that is not trivial. So that
                              should be our horizon for phase 1; I think we all can agree on that
                              as a common goal.

                              And to do that, first we all need to bone up on the VM. Let's get to
                              it. And in the meantime, we can get the administration stuff set up.
                              -Dave
                            • Gilad Bracha
                              Andras, This is fabulous. ... Yes, the friends stuff sounds familiar. I was using VS8, and had a bunch of other issues, mainly about the scope of variables.
                              Message 14 of 30 , Sep 13, 2006
                              View Source
                              • 0 Attachment
                                Andras,

                                This is fabulous. 

                                On Sep 13, 2006, at 2:40 AM, pahihu wrote:

                                --- In strongtalk@yahoogroups.com, Gilad Bracha <gilad@...> wrote:
                                > There are lots of directions one could take this. I think the most
                                > important one is to get the code so it builds properly on modern
                                > tools. It doesn't right now for a variety of reasons that still
                                need
                                > to be fully understood. Obviously, C++ has changed a lot in the
                                last
                                > decade. I've made most of the changes necessary, and have a version
                                > that builds - but it fails to run :-(. We're investigating why that
                                > is the case. I hope we can solve it quickly, but it may be non-
                                > trivial. The leading theory is that the C++ compiler's calling
                                > conventions may have changed, which causes problems in the
                                transition
                                > from assembly code back to C++.

                                Hi,

                                I have changed the sources to compile under VS6 and VS7.1. The main
                                problem was with the friend function declarations and definitions
                                embedded inside the class declarations. That solved easily.
























                                                                                                                                                                      Yes, the friends stuff sounds familiar. I was using VS8, and had a bunch of other issues, mainly about the scope of variables. 
                                That may well have caused new bugs to be introduced.  It's very encouraging that things are moving forward. 

                                Cheers,

                                Gilad


                              • Krzysztof Kowalczyk
                                ... SourceForge and Google Code hosting are the big boys when it comes to project hosting for open-source projects. I was a frequent user of sourceforge.net
                                Message 15 of 30 , Sep 13, 2006
                                View Source
                                • 0 Attachment
                                  > --- In strongtalk@yahoogroups.com, Todd Blanchard <tblanchard@> wrote:
                                  > >
                                  > > A version control system, project admin, and set of trusted
                                  > > reviewers/committers is going to be required.
                                  >
                                  > Not having dealt directly with
                                  > open-source development, I am open to advice on the right tools,
                                  > hosts, etc, if anyone knows a lot about that, so we can do things in
                                  > whatever the current standard way is. There is plenty of room here if
                                  > people want to help.

                                  SourceForge and Google Code hosting are the big boys when it comes to
                                  project hosting for open-source projects.

                                  I was a frequent user of sourceforge.net and I wouldn't recommend it
                                  (cvs/subversion access is (and has been for ages) slow; I also find
                                  their UI not very usable for most of the tools).

                                  Recently I started using Google's open-source hosting
                                  (code.google.com) and I would recommend using that.

                                  At this point it only has subversion hosting and a decent bug tracker.
                                  They have ability to give multiple people commiter access.

                                  SourceForge has much more tools but on the other hand e.g. their bug
                                  tracker is rather bad and few projects end up using it.

                                  Google hosting tends to be slow but it's a new service and I hope
                                  those are growing pains that Google will fix (SourceForge had
                                  scalability problems forever so I no longer believe they'll fix them).

                                  Creating a project on code.google.com is a snap. Having source in
                                  subversion and a bug tracker would be a good start for collaborative
                                  developement.

                                  A wiki for collaborative documentation would also be nice. It's easy
                                  to set one up or there are plenty of free (ad-sponsored, mostly)
                                  hosted wikis.

                                  -- kjk
                                • Tony Garnock-Jones
                                  ... I ve found Darcs (http://www.darcs.net/) works really well for open-source projects. It can be used in a centralised fashion, like CVS, but also supports
                                  Message 16 of 30 , Sep 14, 2006
                                  View Source
                                  • 0 Attachment
                                    Todd Blanchard wrote:
                                    > A version control system, project admin, and set of trusted
                                    > reviewers/committers is going to be required.

                                    I've found Darcs (http://www.darcs.net/) works really well for
                                    open-source projects. It can be used in a centralised fashion, like CVS,
                                    but also supports any position along the scale between completely
                                    centralised and completely decentralised, which allows the team to
                                    naturally discover how they prefer to work with each other.

                                    It also reduces the burden on the reviewers/committers, as if they go
                                    AWOL for a while, someone else's repository can seamlessly take over
                                    until they return and start incorporating patches again.

                                    Regards,
                                    Tony

                                    PS. The release of the Strongtalk VM is extremely exciting! Thanks to
                                    all concerned for making it possible!
                                  • suetanvil
                                    ... wrote: [...] ... wxWidgets is probably the best way to go in the long term (IMHO). In the short term, I d like to suggest considering WineLib
                                    Message 17 of 30 , Sep 14, 2006
                                    View Source
                                    • 0 Attachment
                                      --- In strongtalk@yahoogroups.com, Todd Blanchard <tblanchard@...> wrote:
                                      [...]
                                      > 1) Ditch the Windows UI in favor of wxWidgets. (http://
                                      > www.wxwidgets.org) This will get us a nice portable package with
                                      > native looking GUIs. Quite a few people are using the wx stuff with
                                      > great success. For instance, the Outlook-killer known as Chandler is
                                      > written in Python with bindings to wxWidgets.

                                      wxWidgets is probably the best way to go in the long term (IMHO).

                                      In the short term, I'd like to suggest considering WineLib as an
                                      alternative. This is a Unix library implementing the Win32 API (it's
                                      basically the guts of Wine). If you can get the VM running under
                                      Linux, porting the GUI code to WineLib ought to be trivial.


                                      --Chris




                                    • fmateoc
                                      Dave, You seem to imply that in order to add a debugger there is a need for VM support. Did I understand that correctly? If so, why is it so? I am sorry, I am
                                      Message 18 of 30 , Sep 14, 2006
                                      View Source
                                      • 0 Attachment
                                        Dave,

                                        You seem to imply that in order to add a debugger there is a need for
                                        VM support. Did I understand that correctly? If so, why is it so?
                                        I am sorry, I am not familiar yet with the Strongtalk libraries, but
                                        isn't exception handling implemented in Strongtalk, like in the other
                                        Smalltalks (true, with some vm support for performance reasons, but
                                        conceptually it could all be in Strongtalk if it reifies contexts),
                                        and shouldn't that be enough?

                                        Florin


                                        --- In strongtalk@yahoogroups.com, davegriswold9 <no_reply@...> wrote:
                                        >
                                        > --- In strongtalk@yahoogroups.com, Todd Blanchard <tblanchard@> wrote:
                                        > >
                                        > > A version control system, project admin, and set of trusted
                                        > > reviewers/committers is going to be required.
                                        >
                                        > Yes, indeed. This release came a bit faster than I expected, but I'll
                                        > starting to try to figure this out. Not having dealt directly with
                                        > open-source development, I am open to advice on the right tools,
                                        > hosts, etc, if anyone knows a lot about that, so we can do things in
                                        > whatever the current standard way is. There is plenty of room here if
                                        > people want to help.
                                        >
                                        > The biggest problem is that all the trusted reviewers are pretty busy.
                                        > I at least am definitely going to be spending some non-trivial amount
                                        > of time on this, however I need to do lots of boning up on the VM
                                        > before I would trust myself to review changes to the C++. Gilad I
                                        > think is in a pretty similar situation, although I think there is a
                                        > possibility he might be able to get some help together. Gilad and I
                                        > can deal with pretty much all the Strongtalk code.
                                        >
                                        > The team members who are the real experts on the VM internals are
                                        > unfortunately very busy people, but there might be some hope for a
                                        > little attention from them. One thing I hope to do is to get some of
                                        > them to give talks on the VM internals, and capture them, so we can
                                        > start a little educational effort for those who wish to understand
                                        the VM.
                                        >
                                        > Another reason I am not diving right in with this is that it is not
                                        > clear yet where the community interest is going to drive this thing,
                                        > or whether there are enough people with the right skills and time to
                                        > get this to critical mass. That's what we trying to assess right now.
                                        >
                                        > And just as important, there may be several immediate forks if the VM
                                        > gets used for things other than straight development as Strongtalk.
                                        > If all the interest, for example, is in having Squeak adopt this VM,
                                        > then I would be inclined to focus more on that, since there is already
                                        > an active community working on the libraries. Smalltalk doesn't need
                                        > any more divisions than necessary, and I don't really want to sink any
                                        > effort into finishing and perfecting the Strongtalk libraries if no
                                        > one is going to use them. There's a ton of work to do in the
                                        > libraries and it has pretty much all been done before elsewhere.
                                        >
                                        > But even if the VM is adopted by Squeak, we need at the least a stable
                                        > minimal baseline Strongtalk that is reliable, usable, and ported to
                                        > Linux and Mac, but without any big feature changes compared to now,
                                        > other than maybe a debugger, although that is not trivial. So that
                                        > should be our horizon for phase 1; I think we all can agree on that
                                        > as a common goal.
                                        >
                                        > And to do that, first we all need to bone up on the VM. Let's get to
                                        > it. And in the meantime, we can get the administration stuff set up.
                                        > -Dave
                                        >
                                      • davegriswold9
                                        ... Conceptually, if the reflective interface is robust enough, we shouldn t need any additional VM support, but it s not clear that everything needed is there
                                        Message 19 of 30 , Sep 14, 2006
                                        View Source
                                        • 0 Attachment
                                          --- In strongtalk@yahoogroups.com, "fmateoc" <fmateoc@...> wrote:
                                          >
                                          > Dave,
                                          >
                                          > You seem to imply that in order to add a debugger there is a need for
                                          > VM support. Did I understand that correctly? If so, why is it so?
                                          > I am sorry, I am not familiar yet with the Strongtalk libraries, but
                                          > isn't exception handling implemented in Strongtalk, like in the other
                                          > Smalltalks (true, with some vm support for performance reasons, but
                                          > conceptually it could all be in Strongtalk if it reifies contexts),
                                          > and shouldn't that be enough?
                                          >
                                          > Florin

                                          Conceptually, if the reflective interface is robust enough, we
                                          shouldn't need any additional VM support, but it's not clear that
                                          everything needed is there at the moment. The biggest requirement,
                                          that is one of the things that makes the Strongtalk VM far trickier
                                          than most VMs, is deoptimization, so that compiled code is reverted to
                                          interpreted code automatically during debugging. That support is
                                          already there, as the command-line debugger attests.

                                          But Smalltalk programmers are used to fix-and-continue debugging, as
                                          well as modifying local variables in the debugger, etc, which is
                                          obviously more intrusive than just looking at what is going on. I
                                          suspect that a bit more support from the VM reflective interface will
                                          be required for those.

                                          However, even just a debugger that can show where you are graphically,
                                          single step, and let you graphically inspect the stack and its
                                          variables would be a great first start, and we know that the basic VM
                                          infrastructure is there for that right now, because the command line
                                          debugger does that now, but in a not-very-friendly way. There might
                                          be some reflective API entry points needed to access that
                                          functionality from Smalltalk, however.

                                          So I think a very attainable initial goal should be to get such a
                                          'read-only' debugger working. That shouldn't require any
                                          functionality changes other than maybe some primitive entry points.
                                          -Dave
                                        • pahihu
                                          ... Yes, ... Hi, VS8 port done. I have resolved the issues with the scope variables, but the resulting program crashed both in debug mode (with an assertion)
                                          Message 20 of 30 , Sep 14, 2006
                                          View Source
                                          • 0 Attachment
                                            --- In strongtalk@yahoogroups.com, Gilad Bracha <gilad@...> wrote:
                                            >
                                            Yes,
                                            > the friends stuff sounds familiar. I was using VS8, and had a bunch
                                            > of other issues, mainly about the scope of variables.
                                            > That may well have caused new bugs to be introduced. It's very
                                            > encouraging that things are moving forward.
                                            >
                                            > Cheers,
                                            >
                                            > Gilad
                                            >

                                            Hi,

                                            VS8 port done. I have resolved the issues with the scope
                                            variables, but the resulting program crashed both in debug
                                            mode (with an assertion) and in product mode. Disabling
                                            every optimization did not solve the problem either!

                                            I have tought that I have introduced errors with the rewrite,
                                            but using the /Zc:forScope- switch for the VS8 compiler on the
                                            VS6/VS7.1 sources gave me the same results.

                                            I have compiled the sources with VS7.1 with the /Zc:forScope
                                            switch to mimic the VS8 behavior and both the debug and the
                                            product versions are working (except the crash mentioned in
                                            one of the Smopstone benchmarks).

                                            So the rewrite was ok, but the VS8 sources are not compilable
                                            with VS6 due to the scoping of the for variables.

                                            VS6 produces the most stable VM executable and its linker is
                                            able to convert the OMF object files to COFF, so I remain with
                                            this version.

                                            Regards,
                                            Andras Pahi
                                          • davegriswold9
                                            That s another good idea. In fact, people have already gotten Strongtalk fairly smoothly running on Mac and Linux by using Crossover, and since that uses the
                                            Message 21 of 30 , Sep 14, 2006
                                            View Source
                                            • 0 Attachment
                                              That's another good idea. In fact, people have already gotten
                                              Strongtalk fairly smoothly running on Mac and Linux by using
                                              Crossover, and since that uses the WINE libs, it seems to be a
                                              proof-of-concept that it would work nicely.
                                              -Dave

                                              --- In strongtalk@yahoogroups.com, "suetanvil" <cgreuter@...> wrote:
                                              >
                                              >
                                              > --- In strongtalk@yahoogroups.com, Todd Blanchard <tblanchard@>
                                              > wrote:
                                              > [...]
                                              > > 1) Ditch the Windows UI in favor of wxWidgets. (http://
                                              > > www.wxwidgets.org) This will get us a nice portable package with
                                              > > native looking GUIs. Quite a few people are using the wx stuff with
                                              > > great success. For instance, the Outlook-killer known as Chandler is
                                              > > written in Python with bindings to wxWidgets.
                                              >
                                              > wxWidgets is probably the best way to go in the long term (IMHO).
                                              >
                                              > In the short term, I'd like to suggest considering WineLib
                                              > <http://www.winehq.com/site/winelib> as an
                                              > alternative. This is a Unix library implementing the Win32 API (it's
                                              > basically the guts of Wine). If you can get the VM running under
                                              > Linux, porting the GUI code to WineLib ought to be trivial.
                                              >
                                              >
                                              > --Chris
                                              >
                                            • davegriswold9
                                              Thanks, I ll look into it more. -Dave
                                              Message 22 of 30 , Sep 14, 2006
                                              View Source
                                              • 0 Attachment
                                                Thanks, I'll look into it more.
                                                -Dave

                                                --- In strongtalk@yahoogroups.com, "Krzysztof Kowalczyk"
                                                <kkowalczyk@...> wrote:
                                                >
                                                > > --- In strongtalk@yahoogroups.com, Todd Blanchard <tblanchard@> wrote:
                                                > > >
                                                > > > A version control system, project admin, and set of trusted
                                                > > > reviewers/committers is going to be required.
                                                > >
                                                > > Not having dealt directly with
                                                > > open-source development, I am open to advice on the right tools,
                                                > > hosts, etc, if anyone knows a lot about that, so we can do things in
                                                > > whatever the current standard way is. There is plenty of room here if
                                                > > people want to help.
                                                >
                                                > SourceForge and Google Code hosting are the big boys when it comes to
                                                > project hosting for open-source projects.
                                                >
                                                > I was a frequent user of sourceforge.net and I wouldn't recommend it
                                                > (cvs/subversion access is (and has been for ages) slow; I also find
                                                > their UI not very usable for most of the tools).
                                                >
                                                > Recently I started using Google's open-source hosting
                                                > (code.google.com) and I would recommend using that.
                                                >
                                                > At this point it only has subversion hosting and a decent bug tracker.
                                                > They have ability to give multiple people commiter access.
                                                >
                                                > SourceForge has much more tools but on the other hand e.g. their bug
                                                > tracker is rather bad and few projects end up using it.
                                                >
                                                > Google hosting tends to be slow but it's a new service and I hope
                                                > those are growing pains that Google will fix (SourceForge had
                                                > scalability problems forever so I no longer believe they'll fix them).
                                                >
                                                > Creating a project on code.google.com is a snap. Having source in
                                                > subversion and a bug tracker would be a good start for collaborative
                                                > developement.
                                                >
                                                > A wiki for collaborative documentation would also be nice. It's easy
                                                > to set one up or there are plenty of free (ad-sponsored, mostly)
                                                > hosted wikis.
                                                >
                                                > -- kjk
                                                >
                                              • Daryl Richter
                                                ... +1 for *long term*. I also liked the promise of wx and have have spent the last couple of months trying to get an application delivered using wxWidgets and
                                                Message 23 of 30 , Sep 14, 2006
                                                View Source
                                                • 0 Attachment
                                                  On 9/14/06 2:12 PM, "suetanvil" <cgreuter@...> wrote:

                                                  >
                                                  > --- In strongtalk@yahoogroups.com, Todd Blanchard <tblanchard@...>
                                                  > wrote:
                                                  > [...]
                                                  >> 1) Ditch the Windows UI in favor of wxWidgets. (http://
                                                  >> www.wxwidgets.org) This will get us a nice portable package with
                                                  >> native looking GUIs. Quite a few people are using the wx stuff with
                                                  >> great success. For instance, the Outlook-killer known as Chandler is
                                                  >> written in Python with bindings to wxWidgets.
                                                  >
                                                  > wxWidgets is probably the best way to go in the long term (IMHO).

                                                  +1 for *long term*.

                                                  I also liked the promise of wx and have have spent the last couple of months
                                                  trying to get an application delivered using wxWidgets and Python. I have
                                                  found that it works ok for the simple things, but anything complicated is
                                                  mostly unworkable. There are many subtle problems (with focus, selection,
                                                  keyboard nav, etc.) that our Windows users found unacceptable.

                                                  If you need a grid control... Forget it. ;)

                                                  >
                                                  > In the short term, I'd like to suggest considering WineLib
                                                  > <http://www.winehq.com/site/winelib> as an
                                                  > alternative. This is a Unix library implementing the Win32 API (it's
                                                  > basically the guts of Wine). If you can get the VM running under
                                                  > Linux, porting the GUI code to WineLib ought to be trivial.
                                                  >
                                                  >
                                                  > --Chris
                                                  >

                                                  --
                                                  Daryl
                                                  http://itsallsemantics.com

                                                  "I¹m afraid of the easy stuffŠ its always harder than it seemsŠ"
                                                  -- Bill Hampton, 2006
                                                • davegriswold9
                                                  ... of months ... I have ... complicated is ... selection, ... Having a limited set of native widgets is fine by me; my philosophy in Strongtalk was to imbed
                                                  Message 24 of 30 , Sep 14, 2006
                                                  View Source
                                                  • 0 Attachment
                                                    --- In strongtalk@yahoogroups.com, Daryl Richter <daryl@...> wrote:
                                                    >
                                                    > On 9/14/06 2:12 PM, "suetanvil" <cgreuter@...> wrote:
                                                    >
                                                    > >
                                                    > > --- In strongtalk@yahoogroups.com, Todd Blanchard <tblanchard@>
                                                    > > wrote:
                                                    > [...]
                                                    > > wxWidgets is probably the best way to go in the long term (IMHO).
                                                    >
                                                    > +1 for *long term*.
                                                    >
                                                    > I also liked the promise of wx and have have spent the last couple
                                                    of months
                                                    > trying to get an application delivered using wxWidgets and Python.
                                                    I have
                                                    > found that it works ok for the simple things, but anything
                                                    complicated is
                                                    > mostly unworkable. There are many subtle problems (with focus,
                                                    selection,
                                                    > keyboard nav, etc.) that our Windows users found unacceptable.
                                                    >
                                                    > If you need a grid control... Forget it. ;)

                                                    Having a limited set of native widgets is fine by me; my philosophy in
                                                    Strongtalk was to imbed just the few critical native widgets that help
                                                    in giving a comfortable native look-and-feel, such as menus, buttons,
                                                    scrollbars, listboxes, and dialogs. The idea is to do all the rest in
                                                    Strongtalk; a portable interface for event handling, input focus
                                                    handling, layout, and rendering is already there, so no non-portable
                                                    code would have to be written.

                                                    And in fact it would be pretty easy to implement Smalltalk versions of
                                                    the native widgets, so that no native widgets are used, just GDI-level
                                                    features. See subclasses of Win32Control for the complete set of
                                                    native widgets.

                                                    And then the Squeakers would want a bitblt implementation of the
                                                    GDI-level calls, and then you're pretty much platform independent.
                                                    None of those things should present any basic problem for the
                                                    Strongtalk UI.

                                                    But the UI is quite skeletal right now- lots of things are still
                                                    needed. The basic framework is there, without many leaves on it. I'm
                                                    hesitant to encourage lots of hacking on the UI, until we know more
                                                    about whether the Strongtalk libs are going to be used, or whether
                                                    something like Squeak libs on the Strongtalk VM is the way to go.
                                                    -Dave
                                                  • Gilad Bracha
                                                    Andras, ... Ok, this is great data. I haven t had the time to revisit this - but you are way ahead of me anyway. It sounds like the VS8 crash is not dependent
                                                    Message 25 of 30 , Sep 14, 2006
                                                    View Source
                                                    • 0 Attachment
                                                      Andras,


                                                      On Sep 14, 2006, at 2:23 PM, pahihu wrote:


                                                      Hi,

                                                      VS8 port done. I have resolved the issues with the scope
                                                      variables, but the resulting program crashed both in debug
                                                      mode (with an assertion) and in product mode. Disabling
                                                      every optimization did not solve the problem either!











                                                      Ok, this is great data. I haven't had the time to revisit this - but you are way ahead of me anyway. It sounds like the VS8 crash is not dependent on the coding changes.

                                                      Cheers,

                                                      Gilad


                                                    • davegriswold9
                                                      Hi Andras, Thanks for the binary upload. When we get source control going here in the next couple of days, let s get your source changes into that first
                                                      Message 26 of 30 , Sep 18, 2006
                                                      View Source
                                                      • 0 Attachment
                                                        Hi Andras,

                                                        Thanks for the binary upload. When we get source control going here
                                                        in the next couple of days, let's get your source changes into that
                                                        first thing.

                                                        Are you using MKS Tools for the build? If not, please publicize the
                                                        workaround, since one of the first things we need to do is port away
                                                        from these expensive tools that not everyone wants to pay $500 for.

                                                        Cheers,
                                                        -Dave

                                                        --- In strongtalk@yahoogroups.com, "pahihu" <pahi@...> wrote:
                                                        >
                                                        > --- In strongtalk@yahoogroups.com, Gilad Bracha <gilad@> wrote:
                                                        > >
                                                        > Yes,
                                                        > > the friends stuff sounds familiar. I was using VS8, and had a bunch
                                                        > > of other issues, mainly about the scope of variables.
                                                        > > That may well have caused new bugs to be introduced. It's very
                                                        > > encouraging that things are moving forward.
                                                        > >
                                                        > > Cheers,
                                                        > >
                                                        > > Gilad
                                                        > >
                                                        >
                                                        > Hi,
                                                        >
                                                        > VS8 port done. I have resolved the issues with the scope
                                                        > variables, but the resulting program crashed both in debug
                                                        > mode (with an assertion) and in product mode. Disabling
                                                        > every optimization did not solve the problem either!
                                                        >
                                                        > I have tought that I have introduced errors with the rewrite,
                                                        > but using the /Zc:forScope- switch for the VS8 compiler on the
                                                        > VS6/VS7.1 sources gave me the same results.
                                                        >
                                                        > I have compiled the sources with VS7.1 with the /Zc:forScope
                                                        > switch to mimic the VS8 behavior and both the debug and the
                                                        > product versions are working (except the crash mentioned in
                                                        > one of the Smopstone benchmarks).
                                                        >
                                                        > So the rewrite was ok, but the VS8 sources are not compilable
                                                        > with VS6 due to the scoping of the for variables.
                                                        >
                                                        > VS6 produces the most stable VM executable and its linker is
                                                        > able to convert the OMF object files to COFF, so I remain with
                                                        > this version.
                                                        >
                                                        > Regards,
                                                        > Andras Pahi
                                                        >
                                                      • pahihu
                                                        ... I simply rewrote the supplied Makefile, so I don t need UN*X utilities. I will upload the modified Makefile now. When time permits, I will upload the
                                                        Message 27 of 30 , Sep 19, 2006
                                                        View Source
                                                        • 0 Attachment
                                                          --- In strongtalk@yahoogroups.com, davegriswold9 <no_reply@...> wrote:
                                                          > Are you using MKS Tools for the build? If not, please publicize the
                                                          > workaround, since one of the first things we need to do is port away
                                                          > from these expensive tools that not everyone wants to pay $500 for.

                                                          I simply rewrote the supplied Makefile, so I don't need
                                                          UN*X utilities. I will upload the modified Makefile now.

                                                          When time permits, I will upload the modified source
                                                          as strongtalk-source-1.0.1.zip.

                                                          Regards,
                                                          Andras Pahi
                                                        Your message has been successfully submitted and would be delivered to recipients shortly.