Oberon space
General Category => Общий раздел => Тема начата: Vartovyj от Апрель 08, 2012, 12:28:57 pm
-
Кстати, я тут на Go немного полезного для проекта пописал. Вполне себе язычок. Умеренно годный. Но из за отсутствия "обобщенки" там приходится делать в рантайме (посредством доступа к "метаинформации") то, что можно было бы сделать на этапе компиляции. Причем это на каждом шагу (по крайней мере в той области где я сейчас этот Go применяю). Поэтому ощущения от языка весьма похожи на ощущение от языка с динамической типизацией, хотя конечно все равно много лучше чем ощущения от того же питона например.
Кстати, я тут на Go немного полезного для проекта пописал.
На днях вышла 1 версия Go.
Какие еще впечатления от языка? Годится ли он как замена пхп, питона для написания, скажем, движка динамического сайта?
Я не великий знаток php/python и прочей ереси, опыта в использовании их у меня ну очень мало. Но использую сейчас Go как раз для сайта с ну о-очень динамическим контентом. С реалтаймовым контентом, я бы сказал. :-) И да, Go как раз версии 1.
Я не великий знаток php/python и прочей ереси, опыта в использовании их у меня ну очень мало. Но использую сейчас Go как раз для сайта с ну о-очень динамическим контентом. С реалтаймовым контентом, я бы сказал. :-) И да, Go как раз версии 1.
Под Apache/ngnix или все самописное?
Это в этом проекте отсутствие обобщенки напрягает?
Используются стандартные либы Go. В том числе template/text и template/html. Ну, то есть они вне зависимости от сетевой части использовались бы (апач там или нет). Также используется модуль json. И там и там активно используется рефлекшн. То что могло бы делаться на этапе компиляции, делается в рантайме, со всеми растекающимися последствиями.
Да, а все крутится на google app engine.
Да, а все крутится на google app engine.
Жаль, хотелось бы узнать про опыт написания полноценного независимого приложения.
Полноценное независимое приложение пишется в точности так же. То есть мне код менять не придется (кроме гуглоспецифичных вещей вроде гугловой авторизации). И там и там используется стандартный пакет http.
Грубо говоря, код hello world'a на gae и standalone http server будет один и тот же.
-
Впрочем, лучше один раз увидеть, чем много раз услышать.
Вот hello world писаный на Go и хостящийся на Google App Engine:
package hello
import (
"fmt"
"net/http"
)
func init() {
http.HandleFunc("/", handler)
}
func handler(w http.ResponseWriter, r *http.Request) {
fmt.Fprint(w, "Hello, world!")
}
А вот полный исходник hello world'a на Go без всякого Google App Engine, компилящийся в отдельный исполняемый файл и работающий в режиме "сам себе веб-сервер":
package hello
import (
"fmt"
"net/http"
)
func init() {
http.HandleFunc("/", handler)
http.ListenAndServe(":8080", nil) // < отличие тут
}
func handler(w http.ResponseWriter, r *http.Request) {
fmt.Fprint(w, "Hello, world!")
}
func main() { // < и тут
init()
}
Как видим, отличие только в точке входа (вместо init точкой входа является main) и собственно явным запуском главного цикла.
-
"...Проще говоря, для сохранении равной скорости ответа при «тяжёлой бомбардировке» запросами, реализация на Go требует в 4 раза меньше железа чем Java. И почти в 20 раз меньше «любимого всеми» PHP. Фактически, реальная производительность (учитывая бутылочные горлышки, от которых никуда не деться) приближается к реализации на C/C++."
"...примерно для 7 задач из 10 — Go-фронтенд (включающий в себя и само приложение) справляется с HiLoad успешнее чем Nginx."
Интересно каких?
"...Go изначально неплохо ориентирован на web. Вот, например, два хорошо себя зарекомендовавших фреймворка:
github.com/garyburd/twister (вдохновлённый Tornado/Python)
github.com/hoisie/web.go (вдохновлённый Webpy/Python)
Есть замечательные либы для MongoDB, CouchDB, Redis, Cassandra, SQLite, Mysql. Отличные движки темплетов (помимо встроенного)."
-
Никто не пробовал установить под винду и подключить гуглевый компилятор? http://code.google.com/p/golangide/
-
Никто не пробовал установить под винду и подключить гуглевый компилятор? http://code.google.com/p/golangide/
К сожалению подвиндой не занимаюсь. Так что я пас.
-
Без особых проблем= а в чем дело?
-
Без особых проблем= а в чем дело?
Скачал компилятор и IDE 32bit:
http://code.google.com/p/go/downloads/list?q=OpSys-Windows+Type%3DInstaller
http://code.google.com/p/golangide/downloads/list
настроил, наподобии, как тут сказано:
http://code.google.com/p/golangide/downloads/list
Configure Environment
Menu: View -> Options -> LiteEnv or Welcome: Options -> LiteEnv
Double clicked .env file to editor
Example win32.env
PATH=c:/go/bin;%PATH%
GOROOT=c:/go
GOBIN=c:/go/bin
GOARCH=386
GOOS=windows
в результате, ничего не компилируется, хотя с коммандной строки компилятора все ок.
-
Какой вид проекта создавали go1 или е64? если go1 то вы должны добавить директорию где хранятся файлы проекта в GOPATH (через диалог) и установить ее активной через двойной щелчок в окне Projects (либо через контекстное меню в этом окне), рекомендую создавать е64 -проект (если пути корректны то должен построиться и запуститься без установки GOPATH)
-
А вообще утырков локализаторов - отправить бы в Казань на пост "Дальний"...
-
Вот адрес утырка lockalsash@gmail.com-ведь не постеснялся же его оставить >:(
-
Пасиб, заработало. Как е64 сразу, варианты go1 или просто файл - с бубном.
Жаль нет кросскомпиляции.
-
Это не танцы с бубном- это проект рассчитанный на использование в веб - никаких дополнительных файлов не создается -просто конфигурируются пути (например на папки лежащие в htdoc) - активный проект - содержится в одной из папок и сам компилятор...в ряде случаев крайне удобно...
-
Проект go1 рассчитан на веб?
просто конфигурируются пути (например на папки лежащие в htdoc) - активный проект - содержится в одной из папок и сам компилятор...в ряде случаев крайне удобно...
так в ГО же статическая компиляция...
-
Проект go1 рассчитан на веб?
просто конфигурируются пути (например на папки лежащие в htdoc) - активный проект - содержится в одной из папок и сам компилятор...в ряде случаев крайне удобно...
так в ГО же статическая компиляция...
Причем тут компиляция - речь идет об определении структуры проекта - впрочем , поймете сами...
-
Кстати, согласно вот этому: http://habrahabr.ru/post/141722/ в 32битной винде есть проблема. И в 32битном линуксе тоже (хотя кому он, 32битный, нужен?).
Кратко:
Abtin Forouzandeh обнаружил баг в реализации go для 32-хбитной платформы Windows. Простейшая программа запускается и тут же падает.
По итогам исследования ошибки оказалось, что дело в выделении памяти рантаймом go. В 32-хбитной системе Windows всего доступны 4GB виртуального адресного пространства, верхние 2 из которых зарезервированы для системы, а процессу остаются нижние 2 гигабайта. При запуске программы на go, скомпилированной компилятором 8g рантайм пытается выделить 512 мегабайт виртуального адресного пространства для нужд сборщика мусора. Проблема в том, что память требуется одним куском. Однако в этой реализации языка библиотека KERNELBASE.DLL загружается в середине адресного пространства, выделить протяженный кусок памяти у системы не получается и происходит падение.
-
Проект go1 рассчитан на веб?
так в ГО же статическая компиляция...
Концепция проекта в ide -моделирует его окружение (структуру) -в тех областях для которых ЯП спроектирован (так как воспринимают эти области создатели ide) - а Go планировался производительная альтернатива PHP,Ruby,Python... ну и СИ++ для некоторых видов серверных приложений -разве нет ;) ?
-
Проект go1 рассчитан на веб?
так в ГО же статическая компиляция...
Концепция проекта в ide -моделирует его окружение (структуру) -в тех областях для которых ЯП спроектирован (так как воспринимают эти области создатели ide) - а Go планировался производительная альтернатива PHP,Ruby,Python... ну и СИ++ для некоторых видов серверных приложений -разве нет ;) ?
Не совсем. Go это логическое развитие Limbo, то есть языка общего назначения. В том числе и для всякого там "системного" программирования. Поскольку язык общего назначения, то использовать его можно для чего угодно. Ну, например для веба. Google его там и использует - см. GAE. Это просто та ниша куда гугл его может проще всего пропихнуть пользуясь своим весом на этом рынке и своими сервисами.
Да, а IDE у Go официального нет. :-) Основные разработчики используют Acme (http://acme.cat-v.org/).
-
При запуске программы на go, скомпилированной компилятором 8g рантайм пытается выделить 512 мегабайт виртуального адресного пространства для нужд сборщика мусора.
Oberon warning: fat runtime detected.
Не, ну нахера ему 512 метров на стартапе??? А почему не гигабайт тогда, для ровного счета?
-
При запуске программы на go, скомпилированной компилятором 8g рантайм пытается выделить 512 мегабайт виртуального адресного пространства для нужд сборщика мусора.
Oberon warning: fat runtime detected.
Не, ну нахера ему 512 метров на стартапе??? А почему не гигабайт тогда, для ровного счета?
Где там fat runtime? Оно ПЯМЯТИ не требует 512 метров. Оно требует адресное пространство. В плане памяти там рантайм очень скромный. Скромнее чем у всяких птонов и тем более жаб.
-
Где там fat runtime? Оно ПЯМЯТИ не требует 512 метров. Оно требует адресное пространство. В плане памяти там рантайм очень скромный. Скромнее чем у всяких птонов и тем более жаб.
Я понял, что речь об адресном пространстве. Но его длиннее писать. Итак, нахрена ему 512 метров адресного пространства? :)
-
Где там fat runtime? Оно ПЯМЯТИ не требует 512 метров. Оно требует адресное пространство. В плане памяти там рантайм очень скромный. Скромнее чем у всяких птонов и тем более жаб.
Я понял, что речь об адресном пространстве. Но его длиннее писать. Итак, нахрена ему 512 метров адресного пространства? :)
Чтобы 10 раз за ним не бегать? :-)
-
Чтобы 10 раз за ним не бегать? :-)
Хорошо, почему не гигабайт? :)
-
Чтобы 10 раз за ним не бегать? :-)
Хорошо, почему не гигабайт? :)
Вообще, думаю, что с длинным непрерывным куском адресного пространства просто сборщик мусора проще (и возможно эффективней), чем с фрагментированным адресным пространством. Вот и все. Решили сэкономить на разработке, тем более что целевая система у них сейчас - 64битная (тот же GAE на 64битах крутится), где проблемы с адресными пространствами просто нет.
Почему 512 - хез. Может прикинули максимальный средний объем ОЗУ который потребуется приложению.
PS. Но никто не мешает использовать gccgo, где рантайм другой и этой проблемы нет.
-
Кстати, как я понял, Go резервирует большое адресное пространство для более эффективной работы сборщика мусора. А именно - таким образом они пытаются уменьшить вероятность коллизий консервативного сборщика мусора (а у них он консервативный). Таким образом, проблема не специфична именно что для Go - при любой реализации рантайма (вне зависимости от языка) с консервативным сборщиком мусора приходится выбирать - либо высокая вероятность коллизий (а следовательно и утечек памяти), либо резервируем большое адресное пространство, но тогда будут проблемы на архитектурах с "тесным" адресным пространством (32 битным например).
-
Собственно вот тут: http://code.google.com/p/go/issues/detail?id=909 как раз описание проблемы с утечками на 32битной архитектуры из за мелкого адресного пространства в сочетании с консервативныс сборщиком мусора.
-
Так и не понял что нужно чтобы его подсадить - вроде на XP32 - примитивщина запускается (может версия компилятора была старая...)
-
Да, а IDE у Go официального нет. :-) Основные разработчики используют Acme (http://acme.cat-v.org/).
На безрыбье сойдет и liteide - довольно удобна - в особенности для ознакомления новичками - недочеты допилят за год (если не забросят, конечно).
-
Собственно вот тут: http://code.google.com/p/go/issues/detail?id=909 как раз описание проблемы с утечками на 32битной архитектуры из за мелкого адресного пространства в сочетании с консервативныс сборщиком мусора.
Кстати, цитатка из Вирта (глава 8. Память: разметка и управление):
В случае трех областей (памяти) приходится произвольно определять предельные размеры. Однако наличие аппаратных средств отображения адресов облегчает задачу, потому что виртуальное адресное пространство так велико, что его предел почти никогда не достигается.
Ну и в оригинале:
In the case of three spaces, arbitrarily determined size limits are unavoidable. The presence
of an address-mapping hardware alleviates the problem, however, because the virtual address space is
so large that limits will hardly ever be reached.
-
Дочитал эту главу. Разочарован. Там ничего не сказано про определение корней деверьев, то есть нет ничего про сканирование стека на предмет указателей. Ну и про статические переменные тоже ничего нет.
-
ничего про сканирование стека на предмет указателей
А в том Обероне, кажется, сборщик мусора запускался только между вызовами пользовательских процедур непосредственно из главного цикла операционной системы, то есть на стеке в это время никаких пользовательских объектов нет, сканировать нечего.
-
ничего про сканирование стека на предмет указателей
А в том Обероне, кажется, сборщик мусора запускался только между вызовами пользовательских процедур непосредственно из главного цикла операционной системы, то есть на стеке в это время никаких пользовательских объектов нет, сканировать нечего.
Это как-то уж слишком сурово. То есть если во время вызова NEW обнаружится, что память кончился и нужно вызвать сборщик мусора, то сборщик не вызовется и все радостно трапнется?
Кроме того, статические переменные то все равно надо учитывать. А про это ничего не сказано.
-
Кстати, по прочтению этой главы, у меня появилось ощущение, что GC в ОС Оберон ни разу не консервативный.
-
На заметку - у Go, как оказалось, не просто два компилятора (один gc - корнями уходит в plan9, другой gccgo), а два действительно разных фронтенда. Один фронтенд (у gc) писан на Си, другой фронтенд (у gccgo) писан на С++.
-
valexey, а вот это имеет место быть:
... Например, если вместо
if a > b {
Printf("a > b")
}
написать
if a > b
{
Printf("a > b")
}
то функция Printf() будет вызываться всегда, независимо от значений a и b. При этом компилятор не сообщит об ошибке... Будет выдано только предупреждение. ... может стать источником трудновыявимых ошибокhttp://forum.oberoncore.ru/viewtopic.php?f=26&t=2036&hilit=Google+Go&start=60#p47128 (http://forum.oberoncore.ru/viewtopic.php?f=26&t=2036&hilit=Google+Go&start=60#p47128)
или уже исправили?
-
valexey, а вот это имеет место быть:
... Например, если вместо
if a > b {
Printf("a > b")
}
написать
if a > b
{
Printf("a > b")
}
то функция Printf() будет вызываться всегда, независимо от значений a и b. При этом компилятор не сообщит об ошибке... Будет выдано только предупреждение. ... может стать источником трудновыявимых ошибокhttp://forum.oberoncore.ru/viewtopic.php?f=26&t=2036&hilit=Google+Go&start=60#p47128 (http://forum.oberoncore.ru/viewtopic.php?f=26&t=2036&hilit=Google+Go&start=60#p47128)
или уже исправили?
Не знаю. Скобочки как во втором варианте не пишу (хотя когда-то, лет 5-6 назад, в плюсах скобочки именно так и рисовал).
В принципе, если такое имеет место, то я не сказал бы что это плохо - все скобочки будут расставлять единообразно :-) Хотя конечно лучше бы оно выдавало просто ошибку компиляции.
-
Да... в рантайм такое пропускать не надо бы. Мало ли интер где клацнул случайно, а потом ищи неделю почему оно глючит...
-
Проверил:
package main
import "fmt"
func main() {
if 0 > 1
{
fmt.Printf("a > b")
}
}
Ошибка компиляции:
go build
# _/home/valexey/Projects/go
./hello.go:6: missing condition in if statement
./hello.go:6: false not used
Также ошибка компиляции будет в случае
package main
func main()
{
}
Ошибка такая:
./hello.go:4: syntax error: unexpected semicolon or newline before {
-
Помогите, плз, прикрутить гуй win32 https://github.com/AllenDang/gform к Go.
Setup
go get github.com/AllenDang/gform
go install github.com/AllenDang/gform
не пойму, это ж не под линукс...
-
Помогите, плз, прикрутить гуй win32 https://github.com/AllenDang/gform к Go.
Setup
go get github.com/AllenDang/gform
go install github.com/AllenDang/gform
не пойму, это ж не под линукс...
А что именно не поймешь?
-
Помогите, плз, прикрутить гуй win32 https://github.com/AllenDang/gform к Go.
Setup
go get github.com/AllenDang/gform
go install github.com/AllenDang/gform
не пойму, это ж не под линукс...
А что именно не поймешь?
ни инсталятора ни инструкции что откуда и куда копировать и настраивать, только командная строка по установке в стиле линукса, которая выдает ошибку при запуске с консоли.
-
Помогите, плз, прикрутить гуй win32 https://github.com/AllenDang/gform к Go.
Setup
go get github.com/AllenDang/gform
go install github.com/AllenDang/gform
не пойму, это ж не под линукс...
А что именно не поймешь?
ни инсталятора ни инструкции что откуда и куда копировать и настраивать, только командная строка по установке в стиле линукса, которая выдает ошибку при запуске с консоли.
У тебя Go вообще установлен? В путях прописан как надо? go help что говорит?
У Go свой пакетный менеджер (то о чем давно мечтали любители ББ ;-) ), и никаких инсталляторов для пакетов/либ не нужно на любой платформе. И ничего руками копировать тоже не нужно.
-
C:\Program Files\Go\bin>go env
set GOARCH=386
set GOBIN=
set GOCHAR=8
set GOEXE=.exe
set GOGCCFLAGS=-g -O2 -m32 -mthreads
set GOHOSTARCH=386
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=
set GOROOT=C:\Program Files\Go
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_386
set CGO_ENABLED=1
C:\Program Files\Go\bin>go get github.com/AllenDang/gform
# cd .; git clone https://github.com/AllenDang/gform C:\Program Files\Go\src\pkg
\github.com\AllenDang\gform
package github.com/AllenDang/gform: exec: "git": executable file not found in %P
ATH%
C:\Program Files\Go\bin>
-
а сам git установлен?
-
а сам git установлен?
нет
-
Оно? _ttp://git-scm.com/
-
Установил git, все равно вылетает с кучей ошибок.
-
Установил git, все равно вылетает с кучей ошибок.
Кучу ошибок в студию!
-
C:\Program Files\Go\bin>go get github.com/AllenDang/gform
# github.com/AllenDang/gform
..\src\pkg\github.com\AllenDang\gform\app.go:16: cannot use 8 (type uint) as typ
e uint32 in assignment
..\src\pkg\github.com\AllenDang\gform\bitmap.go:22: cannot use dib.DsBmih.BiWidt
h (type int32) as type int in field value
..\src\pkg\github.com\AllenDang\gform\bitmap.go:23: cannot use dib.DsBmih.BiHeig
ht (type int32) as type int in field value
..\src\pkg\github.com\AllenDang\gform\canvas.go:65: cannot use rc.Left (type int
32) as type int in function argument
..\src\pkg\github.com\AllenDang\gform\canvas.go:65: cannot use rc.Top (type int3
2) as type int in function argument
..\src\pkg\github.com\AllenDang\gform\canvas.go:65: cannot use rc.Right (type in
t32) as type int in function argument
..\src\pkg\github.com\AllenDang\gform\canvas.go:65: cannot use rc.Bottom (type i
nt32) as type int in function argument
..\src\pkg\github.com\AllenDang\gform\canvas.go:81: cannot use w32Rect.Left (typ
e int32) as type int in function argument
..\src\pkg\github.com\AllenDang\gform\canvas.go:81: cannot use w32Rect.Top (type
int32) as type int in function argument
..\src\pkg\github.com\AllenDang\gform\canvas.go:81: cannot use w32Rect.Right (ty
pe int32) as type int in function argument
..\src\pkg\github.com\AllenDang\gform\canvas.go:81: too many errors
C:\Program Files\Go\bin>
-
Дык это ошибки компиляции. Было бы очень странно если бы оно собралось.
Скажем взять вот это:
..\src\pkg\github.com\AllenDang\gform\canvas.go:65: cannot use rc.Right (type in
t32) as type int in function argumentrc - это тип w32.RECT:
type RECT struct {
Left, Top, Right, Bottom int32
}
А функция куда этот Right передается имеет следующую сигнатуру:
func StretchBlt(hdcDest HDC, nXOriginDest, nYOriginDest, nWidthDest, nHeightDest int, hdcSrc HDC, nXOriginSrc, nYOriginSrc, nWidthSrc, nHeightSrc int, dwRop uint)
Следовательно нужна явное приведение типов из int32 к int согласно описанию языка:
Conversions are required when different numeric types are mixed in an expression or assignment. For instance, int32 and int are not the same type even though they may have the same size on a particular architecture.
То есть это не проблема установки/сборки, а косяк в коде либ. Заводи им на гитхабе соответствующий Issue с описанием проблемы.
Все остальные ошибки компиляции - аналогичны.
-
Поправочка - rc это переменная типа w32.RECT
-
По работе пишу сейчас програмку на Go. Напоролся на какую-то невнятную утечку памяти (пока не понятно где именно, но похоже в стандартной либе), в результате память не только жрется и не освобождается со временем, но еще и дико грузится процессор (да-да, постоянно дергается системой сборщик мусора, он идет искать кого там прибить можно, ан никого нельзя, поэтому он работает в холостую, но при этом жрет процентов 80 от всей загрузки). И это конечно минус.
Пришлось познакомиться с профилировщиком гошным. Профилировщик там удобный и доходчивый (и память и CPU), и это плюс (пример использования: http://blog.golang.org/2011/06/profiling-go-programs.html , правда там старая версия, сейчас несколько иначе).
Разбираюсь дальше.
-
Итить колотить! за 30 минут работы в куче валяется миллион (точнее 947007) живых объектов.
-
что это за rabbitware такое? : )
-
что это за rabbitware такое? : )
parser error :-) Что такое rabbitware?
-
Победил:
[03:30:31] <valexеy> есть модуль session, который позволяет куками оперировать. собственно вся инфа хранится на стороне клиента (браузера) а не сервера, ога.
[03:30:58] <valexеy> но при этом при реаизации этой session они заюзали модуль context, который, сволочь, сохраняет в глобальной переменной КАЖДЫЙ реквест!
[03:31:01] <valexеy> от клиента
[03:31:39] <valexеy> и чтобы этого не было нужно кроме модуля session себе заимпортировать модуль context и после обработки реквеста явным образом дергать context.Close(r), где r это request
[03:31:55] <valexеy> пардон, не Close, а Clean
И да, в доке это не отражено.
PS. Самое смешное, что после того как все почистил, если верить профилеровщику, один фиг эти secure cooies жрут CPU больше всех, и мусорят там тоже больше всех. Процентов 70 жрут от оставшегося.
-
Человек делится опытом написания на Go (внимание, английский!): http://corte.si/posts/code/go/go-rant.html
В общем то я с ним согласен - то, что Go считает неиспользованный импорт, или переменную ошибкой - дико раздражает и мешает. Приходится в ходе разработки совершать уйму бесполезных телодвижений.