Hi all!
I've installed the DevKit [dev branch, thanks Dale for your guidence so far] in both my server (Debian Wheezy) and my desktop (OSX), and connect via SSH port forwarding. The seaside gem is now working, the "counter" examples work well, and I tested introducing a divide by zero error to debug via continuation and all went well there. So far so good (with a few hiccups that I managed to resolve on the way). I'm now attempting the same Seaside tutorial that I did a while ago on Pharo (boquitas). I'm stuck now in the simplest Hello World. I get an error in WAInitialRenderLoopContinuation>>createRoot: (error 2010), a Symbol does not understand #'new'". In the freshly installed devKit, the error raises by doing the following:
A couple more questions:
Thanks! _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On Sun, Sep 20, 2015 at 9:48 AM, Ezequiel Tolnay via Glass <[hidden email]> wrote:
You may want to copy the stack of the error? (CMD+Shift+P from the tODE debugger will open the stack in a printable way so that you can copy paste) Also..which version of Seaside did you install?
I am not sure if the script startNetldi allows you to do that. But, what I can tell you for sure is that dealing directly to netldi, DOES allow you to choose ports. For example, this is how I start netldi in my scripts: GEMSTONE_USER -n -P $NETLDI_PORT -p`expr $NETLDI_PORT + 1`:`expr $NETLDI_PORT + 2` -l $APPLICATION_LOG_DIR/netldi$APPLICATION_NAME.log netldi$APPLICATION_NAME > $GEMSTONE_LOGDIR/netldiStartup.log 2>&1' Note the arguments -P and -p .. so you maybe need to have you custom script to start/stop netldi (based on startNetldi script) Or you can convince Dale to add some arguments to #startNetldi :)
Uhhhh this is a very good idea!!! This is for security reasons right?
Good idea. Which kind of socket address object are you instantiating and how do you get an instance out of a string like 'localhost'?
This is very likely because you installed a newer Seaside version whose "ConfigurationOfSeaside" brings different packages by default than what it used to load default. You should simply install the packages/groups you want (like jQuery for example) that are not in the default load. For example, this is what I load: #('Core' 'Zinc-Seaside' 'Javascript' 'JQuery' 'JSON' 'FastCGI' 'Email')
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
Hi,
1- after installing via "./installServer devKit 3.2.8.1" netLDI listens in different random ports each time it starts. How do I get it to listen on the one in the default gs64ldi port 50377 always instead? In /etc/services file add the following line: gs64ldi 50377/tcp # Gemstone netldi 3- GemStone Seaside installation does includes JQuery examples. Seems that something went wrong... :( Regards, Bruno |
> 1- after installing via "./installServer devKit 3.2.8.1" netLDI listens in
> different random ports each time it starts. How do I get it to listen on the > one in the default gs64ldi port 50377 always instead? > > In /etc/services file add the following line: > gs64ldi 50377/tcp # Gemstone netldi To have the devKit_ldi netldi process use the same port each time, also add to /etc/services: devKit_ldi 50378/tcp # DevKit GemStone Network Long Distance Information (LDI) I typically don’t need to add this entry in development - ie. dev and stone on the same machine. The only time I add this entry is when I want my local tODE to connect to a remote stone. I add the stoneName_ldi to both the local and remote /etc/services to ensure they both lookup the same port number cheers _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
Hi Mariano,
Thanks for the feedback! I don't know which version of seaside gets installed, 3.1x apparently. After running "./installServer devKit 3.2.8.1" from a copy of the dev branch of the tODE devKit, as per Dale's instructions, I mounted Seaside in tODE, installed, and registered it as follows:
The stack at the error (continuation from the object log) is the following (the error is in the 15th position): aTDDebugger -------------------- 1. WAGemStoneProductionErrorHandler(WAErrorHandler)>>saveExceptionContinuation: @10 line 7 2. WAGemStoneProductionErrorHandler>>handleDefault: @2 line 3 3. WAGemStoneProductionErrorHandler(WAErrorHandler)>>handleError: @2 line 2 4. WAGemStoneProductionErrorHandler(WAErrorHandler)>>handleGemStoneException: @4 line 4 5. WAGemStoneProductionErrorHandler(WAHtmlHaltAndErrorHandler)>>handleException: @2 line 2 6. [] in WAGemStoneProductionErrorHandler(WAExceptionHandler)>>handleExceptionsDuring: @2 line 5 7. WAGemStoneProductionErrorHandler(ExecBlock)>>on:do: @3 line 42 8. [] in WAGemStoneProductionErrorHandler(WAExceptionHandler)>>handleExceptionsDuring: @2 line 8 9. [] in ExecBlock>>on:do: @4 line 49 10. MessageNotUnderstood(AbstractException)>>_executeHandler: @3 line 8 11. MessageNotUnderstood(AbstractException)>>_signalWith: @1 line 1 12. MessageNotUnderstood(AbstractException)>>signal @2 line 47 13. Symbol(Object)>>doesNotUnderstand: @9 line 10 14. Symbol(Object)>>_doesNotUnderstand:args:envId:reason: @7 line 12 15. [] in WAInitialRenderLoopContinuation>>createRoot @3 line 3 16. GRSmallDictionary>>at:ifAbsent: @8 line 8 17. WAGemStoneRequestContext(WARequestContext)>>rootComponentIfAbsent: @3 line 3 18. WAInitialRenderLoopContinuation>>createRoot @3 line 3 19. WAInitialRenderLoopContinuation>>basicPerformAction @2 line 3 20. [] in WAInitialRenderLoopContinuation(WAActionPhaseContinuation)>>performAction @2 line 2 21. WAInitialRenderLoopContinuation(ExecBlock)>>onException:do: @2 line 66 22. WAInitialRenderLoopContinuation(ExecBlock)>>on:do: @5 line 47 23. WAGemStoneProductionErrorHandler(WAExceptionHandler)>>handleExceptionsDuring: @2 line 3 24. [] in ExecBlock(WARenderLoopContinuation)>>withNotificationHandlerDo: @2 line 20 25. ExecBlock>>on:do: @3 line 42 26. WAInitialRenderLoopContinuation(WARenderLoopContinuation)>>withNotificationHandlerDo: @8 line 21 27. WAInitialRenderLoopContinuation(WAActionPhaseContinuation)>>performAction @2 line 2 28. WAInitialRenderLoopContinuation(WAActionPhaseContinuation)>>handleFiltered: @2 line 2 29. [] in WAInitialRenderLoopContinuation(WARequestHandler)>>handle: @3 line 4 30. WAInitialRenderLoopContinuation(ExecBlock)>>on:do: @3 line 42 31. WACurrentRequestContext class(WADynamicVariable class)>>use:during: @2 line 4 32. [] in WAGemStoneRequestContext(WARequestContext)>>push:during: @2 line 5 33. WAGemStoneRequestContext(ExecBlock)>>ensure: @2 line 12 34. WAGemStoneRequestContext(WARequestContext)>>push:during: @3 line 6 35. WAInitialRenderLoopContinuation(WARequestHandler)>>handle: @2 line 4 36. [] in WAInitialRenderLoopContinuation(WASessionContinuation)>>handle: @2 line 5 37. WAInitialRenderLoopContinuation(ExecBlock)>>on:do: @3 line 42 38. WAInitialRenderLoopContinuation(WASessionContinuation)>>withUnregisteredHandlerDo: @2 line 3 39. WAInitialRenderLoopContinuation(WASessionContinuation)>>handle: @4 line 5 40. WASession>>start @6 line 2 41. [] in WASession>>handleFiltered: @2 line 15 42. WAMergedRequestFields>>at:ifAbsent: @3 line 6 43. WASession>>handleFiltered: @16 line 14 44. [] in WASession(WARequestHandler)>>handle: @3 line 4 45. WASession(ExecBlock)>>on:do: @3 line 42 46. WACurrentRequestContext class(WADynamicVariable class)>>use:during: @2 line 4 47. [] in WAGemStoneRequestContext(WARequestContext)>>push:during: @2 line 5 48. WAGemStoneRequestContext(ExecBlock)>>ensure: @2 line 12 49. WAGemStoneRequestContext(WARequestContext)>>push:during: @3 line 6 50. WASession(WARequestHandler)>>handle: @2 line 4 51. WASession>>handle: @10 line 11 52. WAApplication(WARegistry)>>dispatch:to:key: @4 line 6 53. WAApplication(WARegistry)>>handle:registering: @4 line 7 54. WAApplication>>handleDefault: @3 line 2 55. WAApplication(WARegistry)>>handleFiltered: @7 line 6 56. WAApplication>>handleFiltered: @10 line 8 57. WAExceptionFilter(WARequestFilter)>>handleFiltered: @3 line 4 58. [] in WAExceptionFilter>>handleFiltered: @2 line 7 59. WAExceptionFilter(ExecBlock)>>on:do: @3 line 42 60. WACurrentExceptionHandler class(WADynamicVariable class)>>use:during: @2 line 4 61. [] in WAExceptionFilter>>handleFiltered: @2 line 6 62. WAExceptionFilter(ExecBlock)>>onException:do: @2 line 66 63. WAExceptionFilter(ExecBlock)>>on:do: @5 line 47 64. WAGemStoneProductionErrorHandler(WAExceptionHandler)>>handleExceptionsDuring: @2 line 3 65. WAExceptionFilter>>handleFiltered: @5 line 4 66. [] in WAApplication(WARequestHandler)>>handle: @3 line 4 67. WAApplication(ExecBlock)>>on:do: @3 line 42 68. WACurrentRequestContext class(WADynamicVariable class)>>use:during: @2 line 4 69. [] in WAGemStoneRequestContext(WARequestContext)>>push:during: @2 line 5 70. WAGemStoneRequestContext(ExecBlock)>>ensure: @2 line 12 71. WAGemStoneRequestContext(WARequestContext)>>push:during: @3 line 6 72. WAApplication(WARequestHandler)>>handle: @2 line 4 73. WADispatcher>>handleFiltered:named: @3 line 5 74. WADispatcher>>handleFiltered: @8 line 6 75. [] in WADispatcher(WARequestHandler)>>handle: @3 line 4 76. WADispatcher(ExecBlock)>>on:do: @3 line 42 77. WACurrentRequestContext class(WADynamicVariable class)>>use:during: @2 line 4 78. [] in WAGemStoneRequestContext(WARequestContext)>>push:during: @2 line 5 79. WAGemStoneRequestContext(ExecBlock)>>ensure: @2 line 12 80. WAGemStoneRequestContext(WARequestContext)>>push:during: @3 line 6 81. WADispatcher(WARequestHandler)>>handle: @2 line 4 82. [] in WAGsZincAdaptor(WAServerAdaptor)>>handleRequest: @3 line 4 83. WAGsZincAdaptor(ExecBlock)>>on:do: @3 line 42 84. WAGsZincAdaptor(WAServerAdaptor)>>handleRequest: @2 line 5 85. WAGsZincAdaptor(WAServerAdaptor)>>handle: @2 line 4 86. [] in WAGsZincAdaptor(WAServerAdaptor)>>process: @2 line 6 87. WAGsZincAdaptor(ExecBlock)>>ensure: @2 line 12 88. WAGsZincAdaptor(WAServerAdaptor)>>process: @4 line 7 89. [] in WAGsZincAdaptor>>process: @2 line 6 90. [] in GRGemStonePlatform>>seasideProcessRequestWithRetry:resultBlock: @2 line 12 91. GRGemStonePlatform(ExecBlock)>>on:do: @3 line 42 92. [] in GRGemStonePlatform>>seasideProcessRequestWithRetry:resultBlock: @11 line 13 93. GRGemStonePlatform(ExecBlock)>>ensure: @2 line 12 94. TransientRecursionLock>>critical: @11 line 12 95. GRGemStonePlatform>>seasideProcessRequestWithRetry:resultBlock: @3 line 6 96. [] in GRGemStonePlatform>>seasideProcessRequest:adaptor:resultBlock: @2 line 6 97. Array(Collection)>>do: @5 line 10 98. [] in GRGemStonePlatform>>seasideProcessRequest:adaptor:resultBlock: @3 line 5 99. GRGemStonePlatform(ExecBlock)>>on:do: @3 line 42 100. GRGemStonePlatform>>seasideProcessRequest:adaptor:resultBlock: @2 line 12 101. WAGsZincAdaptor>>process: @3 line 4 102. ZnSeasideServerAdaptorDelegate>>handleRequest: @3 line 4 103. [] in ZnManagingMultiThreadedServer(ZnSingleThreadedServer)>>authenticateAndDelegateRequest: @7 line 12 104. ZnManagingMultiThreadedServer(ZnSingleThreadedServer)>>authenticateRequest:do: @4 line 6 105. ZnManagingMultiThreadedServer(ZnSingleThreadedServer)>>authenticateAndDelegateRequest: @2 line 8 106. [] in ZnManagingMultiThreadedServer(ZnSingleThreadedServer)>>handleRequestProtected: @2 line 5 107. ZnManagingMultiThreadedServer(ExecBlock)>>on:do: @3 line 42 108. ZnManagingMultiThreadedServer(ZnSingleThreadedServer)>>handleRequestProtected: @2 line 6 109. ZnManagingMultiThreadedServer(ZnSingleThreadedServer)>>handleRequest: @5 line 9 110. [] in ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>executeOneRequestResponseOn: @2 line 11 111. ZnManagingMultiThreadedServer(ExecBlock)>>on:do: @3 line 42 112. ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>executeOneRequestResponseOn: @6 line 15 113. [] in ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>executeRequestResponseLoopOn: @2 line 10 114. [] in ZnCurrentServer class(DynamicVariable class)>>value:during: @3 line 9 115. ZnCurrentServer class(ExecBlock)>>ensure: @2 line 12 116. ZnCurrentServer class(DynamicVariable class)>>value:during: @6 line 10 117. [] in ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>executeRequestResponseLoopOn: @4 line 9 118. ZnManagingMultiThreadedServer(ExecBlock)>>on:do: @3 line 42 119. ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>executeRequestResponseLoopOn: @4 line 11 120. [] in ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>serveConnectionsOn: @2 line 17 121. ZnManagingMultiThreadedServer(ExecBlock)>>on:do: @3 line 42 122. [] in ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>serveConnectionsOn: @2 line 18 123. ZnManagingMultiThreadedServer(ExecBlock)>>ensure: @2 line 12 124. [] in ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>serveConnectionsOn: @2 line 20 125. [] in ExecBlock>>ifCurtailed: @2 line 6 126. ExecBlock>>ensure: @2 line 12 127. ZnManagingMultiThreadedServer(ExecBlock)>>ifCurtailed: @3 line 8 128. [] in ZnManagingMultiThreadedServer(ZnMultiThreadedServer)>>serveConnectionsOn: @2 line 23 129. GsProcess>>_start @7 line 16 130. GsNMethod class>>_gsReturnToC @1 line 1 About NetLDI port, I found what the problem is. gs64ldi is the default ldi service name and port, but in devKit the ldi is called devKit_ldi. I added a devKit_ldi to /etc/services and now it works well. According to $GS_HOME/projects/seaside31/install.ston, it looks like it is installing seaside3.1.3.1. I found I don't have a ConfigurationOfSeaside defined. I searched online and found this and run it to test it:
aTDDebugger -------------------- 1. UserDefinedError(AbstractException)>>_signalWith: @5 line 25 2. UserDefinedError(AbstractException)>>signal @2 line 47 3. MetacelloMCVersionSpec(Object)>>error: @6 line 7 4. [] in MetacelloMCVersionSpec(MetacelloVersionSpec)>>resolveToLoadableSpec:forLoad:forMap:packages: @3 line 7 5. [] in MetacelloMCVersionSpec(MetacelloVersionSpec)>>packageNamed:forLoad:forMap:ifAbsent: @33 line 35 6. Dictionary>>at:ifAbsent: @7 line 10 7. MetacelloMCVersionSpec(MetacelloVersionSpec)>>packageNamed:forLoad:forMap:ifAbsent: @2 line 9 8. MetacelloMCVersionSpec(MetacelloVersionSpec)>>resolveToLoadableSpec:forLoad:forMap:packages: @2 line 4 9. [] in MetacelloMCVersionSpec(MetacelloVersionSpec)>>resolveToLoadableSpecs:forLoad:map: @2 line 12 10. [] in ExecBlock1(Set)>>do: @2 line 11 11. [] in ExecBlock2(KeyValueDictionary)>>keysDo: @2 line 7 12. KeyValueDictionary>>keysAndValuesDo: @18 line 15 13. KeyValueDictionary>>keysDo: @2 line 6 14. Set>>do: @3 line 11 15. MetacelloMCVersionSpec(MetacelloVersionSpec)>>resolveToLoadableSpecs:forLoad:map: @13 line 10 16. MetacelloMCVersionSpec(MetacelloVersionSpec)>>resolveToLoadableSpecs: @4 line 12 17. [] in MetacelloMCVersionSpec(MetacelloVersionSpec)>>expandToLoadableSpecNames: @2 line 9 18. [] in ExecBlock1(MetacelloPlatform)>>stackCacheFor:cacheClass:at:doing: @13 line 14 19. [] in ExecBlock0(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: @2 line 9 20. ExecBlock0(ExecBlock)>>on:do: @3 line 42 21. MetacelloGemStonePlatform(MetacelloPlatform)>>useStackCacheDuring:defaultDictionary: @9 line 10 22. MetacelloGemStonePlatform(MetacelloPlatform)>>stackCacheFor:cacheClass:at:doing: @2 line 4 23. MetacelloGemStonePlatform(MetacelloPlatform)>>stackCacheFor:at:doing: @2 line 3 24. MetacelloMCVersionSpec(MetacelloVersionSpec)>>expandToLoadableSpecNames: @6 line 6 25. MetacelloMCVersionSpec>>computeVersionStatus: @2 line 2 26. MetacelloMCVersion>>computeVersionStatus @3 line 9 27. MetacelloMCVersion(MetacelloVersion)>>versionStatus @3 line 3 28. MetacelloMCVersion(MetacelloVersion)>>printOn: @6 line 5 29. MetacelloMCVersion(Object)>>printString @6 line 14 30. TDWorkspaceClientElementBuilder(TDClientSourceElementBuilder)>>printItMenuAction:selectedText: @5 line 7 31. TDWorkspaceClientElementBuilder(TDWindowBuilder)>>handleMenuActions:listElement:actionArg: @12 line 10 32. [] in TDWorkspaceClientElementBuilder(TDClientSourceElementBuilder)>>menuActionBlock @6 line 8 33. TDWorkspaceClientElementBuilder(ExecBlock)>>value:value:value:value:value: @2 line 11 34. GsNMethod class>>_gsReturnToC @1 line 1 Cheers! Ziggy On 21 September 2015 at 00:13, Mariano Martinez Peck <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Good news, I reinstalled the whole thing again from scratch (the latest version in the dev branch) and now it is working!
From Hello World to a full featured website will be a steep uphill, but I finally have a working environment! Stoked :) Cheers! Ziggy On 21 September 2015 at 22:03, Ezequiel Tolnay <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Cool!!! Let me know did you do the zinc thingy to only bind localhost ;) I would also like to have netldi and Zinc only accepting from localhost! On Mon, Sep 21, 2015 at 1:12 PM, Ezequiel Tolnay <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Hi Mariano, How do you set-up "ConfigurationOfSeaside"? I have BaselineOfSeaside3, which extends from ConfigurationOf. Is it the same thing / newer interface? Or is it for a different purpose? How can I load the packages you mentioned in your first response? #('Core' 'Zinc-Seaside' 'Javascript' 'JQuery' 'JSON' 'FastCGI' 'Email') Cheers! Ziggy On 22 September 2015 at 02:43, Ezequiel Tolnay <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On 09/21/2015 09:50 AM, Ezequiel Tolnay via Glass wrote: > Hi Mariano, > > How do you set-up "ConfigurationOfSeaside"? I have BaselineOfSeaside3, > which extends from ConfigurationOf. Is it the same thing / newer > interface? Or is it for a different purpose? How can I load the > packages you mentioned in your first response? #('Core' 'Zinc-Seaside' > 'Javascript' 'JQuery' 'JSON' 'FastCGI' 'Email') > > Cheers! > > Ziggy > I'm glad you worked through your initial issues. I plan to respond to some of your emails to clarify a point or two... You have a baseline because the install script[1] you used does a `project load Seaisde3` which loads Seaside based on the project entry registered with tODE ($GS_HOME/tode/sys/default/projects/seaside) that looks like the following: ^ TDProjectSpecEntryDefinition new baseline: 'Seaside3' repository: 'github://GsDevKit/Seaside31:3.1.?/repository' loads: #('Development' 'Zinc' 'FastCGI' 'Examples'); status: #(#'inactive'); locked: false; yourself A project entry is a specification for a Metacello load and is one of the fundamentals of tODE ... the ability to share a "project load specification" among multiple stones ... In this case the specification is for a `baseline:`. The baseline is the preferred way to load projects that are stored on GitHub ... the ConfigurationOfSeaside ends up loading the same baseline and is maintained to make it easy for folks using cross-platform projects as the Seaside versions for Pharo and Squeak are not maintained on github like the GemStone version is. Seaside3.2 will be loaded from github (thanks to Johan Brichau) and baseline references to Seaside3.2 will become more prevalent . Soooo at the end of the day, a ConfigurationOf and a BaselineOf can end up loading the same code, just via a slightly different path ... Dale [1] https://github.com/GsDevKit/gsDevKitHome/blob/dev/projects/seaside31/install.ston _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
Editing /etc/services is indeed the "approved" method for associating a netldi name with a specific port, but you do have to "figure this out ahead of time" and you have to use root to update /etc/services .... The drawback is that this needs to be done for every stone and a free port either needs to defined ahead of time (like 50377) or the /etc/services entry needs to be added after the netldi figures out which port is free ... I intend to automate this and if folks are comfortable with having to enter their `sudo` password whenever a stone is created, then I can go this route ... if there are (good) reasons for not updating /etc/services on every stone creation, then I can come up with alternate schemes... What do you guys think? Dale On 09/20/2015 09:52 PM, Jupiter Jones via Glass wrote: >> 1- after installing via "./installServer devKit 3.2.8.1" netLDI listens in >> different random ports each time it starts. How do I get it to listen on the >> one in the default gs64ldi port 50377 always instead? >> >> In /etc/services file add the following line: >> gs64ldi 50377/tcp # Gemstone netldi > To have the devKit_ldi netldi process use the same port each time, also add to /etc/services: > > devKit_ldi 50378/tcp # DevKit GemStone Network Long Distance Information (LDI) > > I typically don’t need to add this entry in development - ie. dev and stone on the same machine. The only time I add this entry is when I want my local tODE to connect to a remote stone. I add the stoneName_ldi to both the local and remote /etc/services to ensure they both lookup the same port number > > cheers > _______________________________________________ > Glass mailing list > [hidden email] > http://lists.gemtalksystems.com/mailman/listinfo/glass _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
I personally prefer sending -P and -p arguments to startnetldi and not depend on /etc/services On Mon, Sep 21, 2015 at 2:26 PM, Dale Henrichs via Glass <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
On 09/20/2015 07:13 AM, Mariano Martinez Peck via Glass wrote: > > > This is very likely because you installed a newer Seaside version > whose "ConfigurationOfSeaside" brings different packages by default > than what it used to load default. You should simply install the > packages/groups you want (like jQuery for example) that are not in the > default load. > > For example, this is what I load: > > #('Core' 'Zinc-Seaside' 'Javascript' 'JQuery' 'JSON' 'FastCGI' 'Email') > the packages that you want to have loaded in your standard install ... ^ TDProjectSpecEntryDefinition new baseline: 'Seaside3' repository: 'github://GsDevKit/Seaside31:3.1.?/repository' loads: #('Development' 'Zinc' 'FastCGI' 'Javascript' 'JQuery' 'JSON' 'Email'); status: #(#'inactive'); locked: false; yourself You can `edit /sys/default/projects/seaside` and make the changes in the default hierarchy, but I recommend that you copy the project entry to either the local or stone-specific structure ... add project entries to the `/sys/local/projects` node when you want every one of your stones to load the project with that project entry: cp /sys/default/projects/seaside /sys/local/projects edit /sys/local/projects/seaside #make your changes or add the project entry to your stone's project directory to customize the load for that particular stone: cp /sys/default/projects/seaside /sys/stone/projects edit /sys/stone/projects/seaside #make your changes Dale _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
Hi Dale, I prefer manually editing /etc/services, just make sure the documentation mentions the need to do that. Sincerely, Alejandro On Mon, Sep 21, 2015 at 2:30 PM, Mariano Martinez Peck via Glass <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
On Mon, Sep 21, 2015 at 1:50 PM, Ezequiel Tolnay <[hidden email]> wrote:
As you may know, finding documentation in Smalltalk world is not always a walk in the park. Fortunately, Dale, GemStone in general and Pharo have been doing much more than what we would find in other places. Anyway...thing is, there is a chapter about Metacello we wrote with Stef and reviewed by Dale. Is probably a bit outdated, but it will give you a MUCH better understanding of Metacello. I really recommend to read that before continue doing stuff with Metacello.
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
On 09/21/2015 05:03 AM, Ezequiel Tolnay
via Glass wrote:
Ziggy, I strongly recommend that when using GLASS/GsDevKit, that you use the Metacello Scripting API for loading projects[1] (or project entries). With the Metacello Scripting API you would replace the above expression with something like the following: Metacello new configuration: 'Seaside'; repositiry: 'http://www.squeaksource.com/MetacelloRepository'; version: #release3 load This "new" style of loading projects takes advantage of the Metacello project registry that tracks the exact version of a project that is loaded... The old style of loading would try to calculate the version of a project that was already loaded and while most of the time, it calculated correctly occasionally it would get it wrong and unhappiness would follow:) If you use the scripting API for loading into GLASS, then the projects will show up in the tODE `project list` and you'll be able to leverage the `project` command for working with your projects... Dale [1] https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md#metacello-user-guide _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
Hi Ezequiel,
Quick question and then I answer inline. ..Just to know how much I should test this...did you really test it? I mean, with and without the changes and trying to access from outside localhost? On Mon, Sep 21, 2015 at 1:43 PM, Ezequiel Tolnay <[hidden email]> wrote:
Cool, easy.
For me it easy because I start netldi with my custom scripts. BTW... note that the argument is "-A" (uppercase), not "-a" as you show above because that's another argument (" all processes started by the netldi will belong to this account."). I guess it was an email writing problem and you were using -A instead ?
mmmmm I don't have any #bindingAddressOn: method defined anywhere. Maybe it's because of the version of Seaside I am using. Could you please share with me which class implements such a method and which is the source code of such method ? Thanks in advance,
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Hi Mariano,
The -a (low caps) was a typo, oops! Until I get the hang of the smalltallkers lingo, any instructions I write will be confusing!
I probably shouldn't have said edit. Copy the method WAServerAdaptor class>>startOn:, and add to it the following extra parameter:
The code is small enough, I reckon it is easier to just write it here haha! New method WAServerAdaptor class>>startOn: portInteger bindingAddressOn: aBindingAddress "Convenience method to start a single adaptor on the specified port. If an existing adaptor of this type is already registered, it will be restarted on the specified port." | adaptor | adaptor := self default. adaptor isNil ifFalse: [ adaptor stop; port: portInteger ] ifTrue: [ adaptor := self port: portInteger ]. adaptor server bindingAddress: aBindingAddress. adaptor start Update WAGemStoneRunSeasideGems>>startOn: port self adaptorClass startOn: port bindingAddressOn: '127.0.0.1' Cheers! Ziggy On 22 September 2015 at 11:54, Mariano Martinez Peck <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Thanks Ezequiel! On Tue, Sep 22, 2015 at 7:35 AM, Ezequiel Tolnay <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Ziggy,
I've added a feature request for this[1] ... sounds like a good addition. Dale [1] https://github.com/GsDevKit/Seaside31/issues/79 On 09/22/2015 06:00 AM, Mariano
Martinez Peck via Glass wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
On Tue, Sep 22, 2015 at 10:59 PM, Jupiter Jones <[hidden email]> wrote:
Hi Jupiter, Thanks for your answer. That's clearly the difference. I assumed you were going via SSH tunneling for the port forwarding. But you are saying ports are open. Ok, forget what I asked.
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Free forum by Nabble | Edit this page |